Golang

C# или 1000 и 1 фича

Java и Spring головного мозга

Javascript

https://habrahabr.ru/post/335004/

https://habrahabr.ru/post/335002/

https://habrahabr.ru/post/334996/

Язык C++ сильно изменился за последние 10 лет. Изменились даже базовые типы: struct, union и enum. Сегодня мы кратко пройдёмся по всем изменениям от C++11 до C++17, заглянем в C++20 и в конце составим список правил хорошего стиля.

Зачем нужен тип struct

Тип struct — фундаментальный. Согласно C++ Code Guidelines, struct лучше использовать для хранения значений, не связанных инвариантом. Яркие примеры — RGBA-цвет, вектора из 2, 3, 4 элементов или информация о книге (название, количество страниц, автор, год издания и т.п.).

Правило C.2: Use class if the class has an invariant; use struct if the data members can vary independently

struct BookStats
{
    std::string title;
    std::vector authors;
    std::vector tags;
    unsigned pageCount = 0;
    unsigned publishingYear = 0;
};

Он похож на class, но есть два мелких различия:

• по умолчанию в struct действует видимость public, а в class — private
• по умолчанию struct наследует члены базовых структур/классов как публичные члены, а class — как приватные члены

// поле data публичное
struct Base
{
    std::string data;
};

// Base унаследован так, как будто бы написано `: public Base`
struct Derived : Base
{
};

Согласно C++ Core Guidelines, struct хорошо применять для сокращения числа параметров функции. Этот приём рефакторинга известен как "parameter object".

Правило C.1: Organize related data into structures (structs or classes)

Кроме того, структуры могут сделать код более лаконичным. Например, в 2D и 3D графике удобнее считать в 2-х и 3-х компонентных векторах, чем в числах. Ниже показан код, использующий библиотеку GLM (OpenGL Mathematics)

// Преобразует полярные координаты в декартовы
// См. https://en.wikipedia.org/wiki/Polar_coordinate_system
glm::vec2 euclidean(float radius, float angle)
{
    return { radius * cos(angle), radius * sin(angle) };
}

// Функция делит круг на треугольники,
//  возвращает массив с вершинами треугольников.
std::vector TesselateCircle(float radius, const glm::vec2& center, IColorGenerator& colorGen)
{
    assert(radius > 0);

    // Круг аппроксимируется с помощью треугольников.
    // Внешняя сторона каждого треугольника имеет длину 2.
    constexpr float step = 2;
    // Число треугольников равно длине окружности, делённой на шаг по окружности.
    const auto pointCount = static_cast(radius * 2 * M_PI / step);

    // Вычисляем точки-разделители на окружности.
    std::vector points(pointCount);
    for (unsigned pi = 0; pi < pointCount; ++pi)
    {
        const auto angleRadians = static_cast(2.f * M_PI * pi / pointCount);
        points[pi] = center + euclidean(radius, angleRadians);
    }

    return TesselateConvexByCenter(center, points, colorGen);
}

Эволюция struct

В C++11 появилась инициализация полей при объявлении.

struct BookStats
{
    std::string title;
    std::vector authors;
    std::vector tags;
    unsigned pageCount = 0;
    unsigned publishingYear = 0;
};

Ранее для таких целей приходилось писать свой конструктор:

// ! устаревший стиль !
struct BookStats
{
    BookStats() : pageCount(0), publishingYear(0) {}

    std::string title;
    std::vector authors;
    std::vector tags;
    unsigned pageCount;
    unsigned publishingYear;
};

Вместе с инициализацией при объявлении пришла проблема: мы не можем использовать литерал структуры, если она использует инициализацию полей при объявлении:

// C++11, C++14: будет ошибка компиляции из-за инициализаторов pageCount и publishingYear
// C++17: компиляция проходит
const auto book = BookStats{
    u8"Незнайка на Луне",
    { u8"Николай Носов" },
    { u8"детская", u8"фантастика" },
    576,
    1965
};

В C++11 и C++14 это решалось вручную написанием конструктора с boilerplate кодом. В C++17 ничего дописывать не надо — стандарт явно разрешает литеральную инициализацию для структур с инициализаторами полей.

В примере написаны конструкторы, необходимые только в C++11 и C++14:

struct BookStats
{
    // ! устаревший стиль!
    BookStats() = default;

    // ! устаревший стиль!
    BookStats(
        std::string title,
        std::vector authors,
        std::vector tags,
        unsigned pageCount,
        unsigned publishingYear)
        : title(std::move(title))
        , authors(std::move(authors))
        , tags(std::move(authors)) // ;)
        , pageCount(pageCount)
        , publishingYear(publishingYear)
    {
    }

    std::string title;
    std::vector authors;
    std::vector tags;
    unsigned pageCount = 0;
    unsigned publishingYear = 0;
};

В C++20 литеральная инициализация обещает стать ещё лучше! Чтобы понять проблему, взгляните на пример ниже и назовите каждое из пяти инициализируемых полей. Не перепутан ли порядок инициализации? Что если кто-то в ходе рефакторинга поменяет местами поля в объявлении структуры?

const auto book = BookStats{
    u8"Незнайка на Луне",
    { u8"Николай Носов" },
    { u8"детская", u8"фантастика" },
    1965,
    576
};

В C11 появилась удобная возможность указать имена полей при инициализации структуры. Эту возможность обещают включить в C++20 под названием "назначенный инициализатор" ("designated initializer"). Подробнее об этом в статье Дорога к С++20.

// Должно скомпилироваться в C++20
const auto book = BookStats{
    .title = u8"Незнайка на Луне",
    .authors = { u8"Николай Носов" },
    .tags = { u8"детская", u8"фантастика" },
    .publishingYear = 1965,
    .pageCount = 576
};

Зачем нужен тип union

Вообще-то в C++17 он не нужен в повседневном коде. C++ Core Guidelines предлагают строить код по принципу статической типобезопасности, что позволяет компилятору выдать ошибку при откровенно некорректной обработке данных. Используйте std::variant как безопасную замену union.

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

// ! этот код ужасно устрарел !
// Event имет три поля: type, mouse, keyboard
// Поля mouse и keyboard лежат в одной области памяти
struct Event
{
    enum EventType {
        MOUSE_PRESS,
        MOUSE_RELEASE,
        KEYBOARD_PRESS,
        KEYBOARD_RELEASE,
    };

    struct MouseEvent {
        unsigned x;
        unsigned y;
    };

    struct KeyboardEvent {
        unsigned scancode;
        unsigned virtualKey;
    };

    EventType type;
    union {
        MouseEvent mouse;
        KeyboardEvent keyboard;
    };
};

Эволюция union

В C++11 вы можете складывать в union типы данных, имеющие собственные конструкторы. Вы можете объявить свой констуктор union. Однако, наличие конструктора ещё не означает корректную инициализацию: в примере ниже поле типа std::string забито нулями и вполне может быть невалидным сразу после конструирования union (на деле это зависит от реализации STL).

// ! этот код ужасно устрарел !
union U
{
   unsigned a = 0;
   std::string b;

   U() { std::memset(this, 0, sizeof(U)); }
};

// нельзя так писать - поле b может не являться корректной пустой строкой
U u;
u.b = "my value";

В C++17 код мог бы выглядеть иначе, используя variant. Внутри variant использует небезопасные конструкции, которые мало чем отличаются от union, но этот опасный код скрыт внутри сверхнадёжной, хорошо отлаженной и протестированной STL.

#include 

struct MouseEvent {
    unsigned x = 0;
    unsigned y = 0;
};

struct KeyboardEvent {
    unsigned scancode = 0;
    unsigned virtualKey = 0;
};

using Event = std::variant<
    MouseEvent,
    KeyboardEvent>;

Зачем нужен тип enum

Тип enum хорошо использовать везде, где есть состояния. Увы, многие программисты не видят состояний в логике программы и не догадываются применить enum.

Ниже пример кода, где вместо enum используют логически связанные булевы поля. Как думаете, будет ли класс работать корректно, если m_threadShutdown окажется равным true, а m_threadInitialized — false?

// ! плохой стиль !
class ThreadWorker
{
public:
    // ...

private:
    bool m_threadInitialized = false;
    bool m_threadShutdown = false;
};

Мало того что здесь не используется atomic, который скорее всего нужен в классе с названием Thread*, но и булевы поля можно заменить на enum.

class ThreadWorker
{
public:
    // ...

private:
    enum class State
    {
        NotStarted,
        Working,
        Shutdown
    };

    // С макросом ATOMIC_VAR_INIT вы корректно проинициализируете atomic на всех платформах.
    // Менять состояние надо через compare_and_exchange_strong!
    std::atomic = ATOMIC_VAR_INIT(State::NotStarted);
};

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

// ! плохой стиль !
void FillSlide(unsigned slideNo)
{
    switch (slideNo)
    {
        case 1:
            setTitle("...");
            setPictureAt(...);
            setTextAt(...);
            break;
        case 2:
            setTitle("...");
            setPictureAt(...);
            setTextAt(...);
            break;
        // ...
    }
}

Даже если хардкод слайдов оправдан, ничто не может оправдать магические числа. Их легко заменить на enum, и это по крайней мере повысит читаемость.

enum SlideId
{
    Slide1 = 1,
    Slide2,
    Slide3,
    Slide4
};

Иногда enum используют как набор флагов. Это порождает не очень наглядный код:

// ! этот код - сомнительный !
enum TextFormatFlags
{
    TFO_ALIGN_CENTER = 1 << 0,
    TFO_ITALIC = 1 << 1,
    TFO_BOLD = 1 << 2,
};

unsigned flags = TFO_ALIGN_CENTER;
if (useBold)
{
    flags = flags | TFO_BOLD;
}
if (alignLeft)
{
    flag = flags & ~TFO_ALIGN_CENTER;
}
const bool isBoldCentered = (flags & TFO_BOLD) && (flags & TFO_ALIGN_CENTER);

Возможно, вам лучше использовать std::bitset:

enum TextFormatBit
{
    TextFormatAlignCenter = 0,
    TextFormatItalic,
    TextFormatBold,

    // Значение последней константы равно числу элементов,
    //  поскольку первый элемент равен 0, и без явно
    //  указанного значения константа на 1 больше предыдущей.
    TextFormatCount
};

std::bitset flags;
flags.set(TextFormatAlignCenter, true);
if (useBold)
{
    flags.set(TextFormatBold, true);
}
if (alignLeft)
{
    flags.set(TextFormatAlignCenter, false);
}
const bool isBoldCentered = flags.test(TextFormatBold) || flags.test(TextFormatAlignCenter);

Иногда программисты записывают константы в виде макросов. Такие макросы легко заменить на enum или constexpr.

Правило Enum.1: предпочитайте макросам перечислимые типы

// ! плохой стиль - даже в C99 этого уже не требуется !
#define RED   0xFF0000
#define GREEN 0x00FF00
#define BLUE  0x0000FF
#define CYAN  0x00FFFF

// стиль, совместимый с C99, но имена констант слишком короткие
enum ColorId : unsigned
{
    RED = 0xFF0000,
    GREEN = 0x00FF00,
    BLUE = 0x0000FF,
    CYAN = 0x00FFFF,
};

// стиль Modern C++
enum class WebColorRGB
{
    Red = 0xFF0000,
    Green = 0x00FF00,
    Blue = 0x0000FF,
    Cyan = 0x00FFFF,
};

Эволюция enum

В С++11 появился scoped enum, он же enum class или enum struct. Такая модификация enum решает две проблемы:

• область видимости констант enum class — это сам enum class, т.е. снаружи вместо Enum e = EnumValue1 вам придётся писать Enum e = Enum::Value1, что гораздо нагляднее
• enum конвертируется в целое число без ограничений, а в enum class для этого потребуется static cast: const auto value = static_cast(Enum::Value1)

Кроме того, для enum и scoped enum появилась возможность явно выбрать тип, используемый для представления перечисления в сгенерированном компилятором коде:

enum class Flags : unsigned
{
    // ...
};

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

// enum в языке Swift
enum Barcode {
    // вместе с константой upc хранятся 4 поля типа Int
    case upc(Int, Int, Int, Int)
    // вместе с константой qrCode хранится поле типа String
    case qrCode(String)
}

Такой enum эквивалентен типу std::variant, вошедшему в C++ в стандарте C++ 2017. Таким образом, std::variant заменяет enum в поле структуры и класса, если этот enum по сути обозначает состояние. Вы получаете гарантированное соблюдение инварианта хранимых данных без дополнительных усилий и проверок. Пример:

struct AnonymousAccount
{
};

struct UserAccount
{
    std::string nickname;
    std::string email;
    std::string password;
};

struct OAuthAccount
{
    std::string nickname;
    std::string openId;
};

using Account = std::variant;

Правила хорошего стиля

Подведём итоги в виде списка правил:

• C.1: организуйте логически связанные данные в структуры или классы
• C.2: используйте class если данные связаны инвариантом; используйте struct если данные могут изменяться независимо
  
  • C.8: используйте class вместо struct, если хотя бы одно поле не публичное
• указывайте инициализаторы полей, без них вы получите неинициализированные поля с мусором
  
  • не инициализируйте поля нулями в конструкторах, полагайтесь на инициализаторы полей
• в общем случае не пишите конструкторы структур, используйте литеральную инициализацию
• используйте std::variant как безопасную замену union вместо структуры или класса, если данные находятся строго в одном из нескольких состояний, и в некоторых состояниях некоторые поля теряют смысл
• используйте enum class или std::variant для представления внутреннего состояния объектов
  
  • предпочитайте std::variant, если в разных состояниях класс способен хранить разные поля данных
• используйте enum class вместо enum в большинстве случаев
  
  • используйте старый enum если вам крайне важна неявная конвертация enum в целое число
  • используйте enum class или enum вместо магических чисел
  • используйте enum class, enum или constexpr вместо макросов-констант

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

Какие типы из C++17 вы применяли в production?

	std::optional
	std::variant
	std::any
	std::string_view
	std::filesystem::path
	я не вкусил радости применения STL из C++17
	мы не используем C++ STL

Проголосовало 2 человека. Воздержалось 2 человека.

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

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334988/

Друзья, добро пожаловать! Ниже вас ждет история о том, как было проанализировано 20 миллионов доменных имен и что из этого вышло. Результаты можно посмотреть скачав csv-файл или восстановив дамп базы данных в PostgreSQL.

При желании можно поиграться с исходниками здесь или сразу с контейнерами, используя

version: "2"
services:
  app:
    image: danieljust/domain-finder-v1
    tty: true
    ports:
      - "3000:3000"
  rabbit:
    image: rabbitmq:3
  db:
    image: postgres
    environment:
      POSTGRES_PASSWORD: example
      POSTGRES_USER: postgres
      POSTGRES_DB: postgres

Инструкцию можно найти также на гитхабе
Приятного чтения!

Disclaimer!

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

Вступление

У многих компаний, желающих провести ребрендинг или только-только выходящих на широкий рынок, возникает желание подобрать красивый домен.
Любопытства ради, было решено в качестве красивых доменов посмотреть короткие 1-3 символьные домены.

Терминология

• top-level domain (TLD) — домен верхнего уровня;
• second-level domain (SLD) — домен второго уровня.
  Пример vk.com — в данном случае vk = SLD, com = TLD.

Структура таблицы в базе данных

id — идентификатор записи
sldlength — длина домена второго уровня
tld — домен верхнего уровня
domain — собственно доменное имя
price — цена в долларах
roubleprice — цена в рублях
available — флаг, показывающий доступность домена
definitive — флаг, показывающий был ли флаг available сверен с реестром

Результат

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

2.pizza — Идеально подойдет для начинающей пиццерии;
0.fail — для сверхнадежного чего-нибудь;
a.xyz, ab.xyz — для желающих быть поближе к гуглу;
ad.money — для рекламной площадки;
as.guru, as.mba — для консультационных фирм;
at.network — для фирм, связанных с администрированием сетей;
js.army — пролетарии всех стран, объединяйтесь.

Большинство двухсимвольных доменов, если и оказывались свободными, то их цена кусалась.
В двухсимвольных доменах верхнего уровня стран было найдено четыре свободных домена (все в чешской зоне), да и к тому же за небольшие деньги в 1000 рублей.
В трехсимвольных доменах верхнего уровня стран нашлось куда больше свободных и по доступной цене.
Количество общих доменов верхнего уровня многократно преобладает над доменами стран (домены стран составляют лишь 4% от общего числа свободных доменных имен)

Путь к результатам

Этап 1. Начало

За основу возможных символов в SLD были взяты -1234567890abcdefghijklmnopqrstuvwxyz (всего 37 символов).
Выясняется, что имеем мы число размещений с повторениями p^n.
Итого $\$inline\$\; 37+37\backslash *37+37\backslash *37\backslash *37\; =\; 52059\; \$inline\$$ вариантов.
Поскольку SLD не может начинаться и заканчиваться дефисом, исключим такие случаи и получим 49284.
Но это только начало.

Этап 2. Выбор API

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

1. предоставьте нам паспортные данные, а мы вам доступ к API;
2. заплатите нам всего лишь раз (от 5 до 15 долларов) и получите пожизненный доступ к API;
3. оплата доступа к API раз в месяц;
4. каждый запрос к API стоимостью около $0,01.

Но душа хотела привнести что-нибудь полезное в мир open-source да еще и максимально бесплатно.
Решением проблемы стало данное API.

Его плюсы:

1. бесплатный;
2. позволяет обработать до 500 доменов за один запрос;
3. проработанная API документация.

Его минусы:

1. ограниченное количество запросов в минуту;
2. ответы от сервера не всегда совпадают с тем, что предлагает UI.

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

Как быть уверенным в доступности домена?

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

Этап 3. Выбор инструментов и подготовка решения

С помощью API godaddy можно получить список TLD, в которых возможно приобрести доменные имена.
Из них выбираются TLD состоящие из одного слова (были убраны *.com.ru и т.д.). В итоге 400 TLD. Легкая арифметика приводит нас к $\$inline\$\; 49284*400\; =\; 19\; 713\; 600\; \$inline\$$ доменов к проверке.
API godaddy может обработать до 500 доменов за 1 запрос, но имеет ограниченное количество запросов в 1 минуту.
В соответствии с вышесказанным, алгоритм работы программы был следующим:

1. разделить все необходимые к проверке домены на куски по 5000 доменов;
2. положить полученные куски в RabbitMQ очередь;
3. взять порцию данных;
4. поделить по 500 доменов. Отправить 10 запросов;
5. обработать данные, положить информацию о свободных доменах в базу данных;
6. подождать 20 секунд;
7. при наличии сообщений в очереди выполнить пункты 3-6 снова.

Для удобства PostgreSQL и RabbitMQ были подняты как docker-контейнеры.

Этап 4. Анализ данных

После того, как с работой скрипта было покончено, возникла необходимость выудить из полученных данных что-нибудь интересное и полезное.
Данные любезно помещены в domains.sql и domains.csv.

Под фильтрацией в дальнейшем подразумевается поиск найденных SLD в списке самых частых английских сочетаний букв в соответствии с этим источником

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

Пятерка самых дорогих доменных имен

Пятерка самых дешевых доменных имен

Заключение

That's all Folks!

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

https://habrahabr.ru/post/334992/

Что самое ценное для IT-компании? Что является главным активом и ресурсом почти для каждой IT-компании? На что компания тратит больше всего денег? Какая статья затрат является самой большой? На обслуживание какого ресурса у вас уходит больше всего денег? Не сильно ошибусь, если скажу, что ответом на все эти вопросы является “Команда компании”. Именно ваша команда делает проекты, двигает вашу компанию вперед и зарабатывает деньги, и именно на зарплаты, бонусы, налоги, оборудование рабочих мест и прочие прямые и косвенные выплаты вашей команде приходится основная масса затрат компании.

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

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

Свое понимание планирую изложить примерно так:

1. Что такое ресурсный план? Тут нарисуем картинку, дадим некоторые определения и расскажем, чем люди отличаются от денег.
2. На что влияет ресурсный план? Рассмотрим сферы деятельности IT-компаний, которые, оказывается, напрямую зависят от качества ресурсного планирования. И если у вас ресурсное планирование не осуществляется на должном уровне или вдруг у вас его вообще нет, то, может быть, после прочтения этой части у вас появятся закономерные вопросы.
3. Что влияет на ресурсный план? Рассматриваем обратную задачу — от чего зависит ресурсный план, что стоит на входе и определяет форму, размер и специфику ресурсного плана
4. Ресурсное планирование в рамках изолированного проекта. Это ресурсное планирование с точки зрения руководителя конкретного проекта, у которого есть понимание задачи, бюджет и нужно сформировать команду и реализовать проект. Также, тут запланирован чек-лист, пробежав по которому можно будет понять, а все ли необходимое мы включили в ресурсный план?
5. Ресурсное планирование портфеля проектов или программы. А это уже ресурсное планирование с точки зрения программного директора, руководителя портфеля проектов, ресурсного менеджера или руководителя компании, где одновременно идет множество проектов, все они находятся на разных фазах и во всех них и требуются и высвобождаются ресурсы.
6. Долгосрочное ресурсное планирование. Если дойдем до этого пункта, то рассмотрим задачу управления ресурсными пулами компании в долгосрочной перспективе.

Что такое ресурсный план?

Для затравки приведу пример ресурсного плана

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

Если попробовать погуглить на тему resource management/resource planning tool, то вы получите довольно внушительный список платных (в большинстве своем) и бесплатных инструментов, которые в той или иной мере помогают в решении задачи управления ресурсами. Ну а мы будем пользоваться старым добрым MS Excel.

Теперь давайте договоримся о терминах:

• Ресурс — специалист с необходимой специализацией и опытом. Причем, под опытом понимается не только совокупное количество лет, которое человек уже успел посвятить своей профессии, но и опыт работы с конкретными проектами. Это ключевой момент и мы к нему еще вернемся.
  
  
• Внутренний ресурсный пул — отдел или подразделение, обладающее необходимыми ресурсами, которые могут использоваться на проекте. Примеры: отдел/департамент FrontEnd, отдел/департамент QA, отдел/департамент управления проектами и т.п. По сравнению с внешними ресурсными пулями, плюсы внутренних — эффективные коммуникации, гарантированная квалификация, хорошая управляемость. Минусы — плохо масштабируются.
  
  
• Внешний ресурсный пул — компания или специалисты, внешние по отношению к компании, которая реализует проект, которые имеют необходимые ресурсы и готовы предоставлять их проекту во временное пользование. Примеры: сайты фрилансеров, компании, специализирующиеся на аутсорсе, партнерские компании с временно недозагруженными ресурсами. Плюсы по сравнению с внутренними ресурсными пулами: отлично масштабируются. Минусы: сложность коммуникаций, дорогое управление, негарантированное качество ресурсов, стоимость, накладные расходы на администрирование.
  
  
• Несогласованный (незастафленный) ресурсный план — это заявка на ресурсы для выполнения проекта. Такой ресурсный план говорит о том, какие ресурсы, когда, в каком количестве и на какой период нужны вам для того, чтобы вы успешно выполнили свой проект. При этом, вместо имен и фамилий в таком плане стоят прочерки или пробелы — реальных людей еще нет, вы их только хотите получить. Пока вы только можете определить требования к специалистам, которые вам нужны, и, может быть, сформулировать пожелания к ресурсным менеджерам относительно конкретных кандидатур, которых вы хотели бы видеть у себя на проекте. Некоторые позиции, конечно же, могут быть уже “застафлены” — прописаны конкретные имена людей, в отношении которых вы уже имеете подтверждение об их участии в вашем проекте.
  
  
• Согласованный (застафленный) ресурсный план — это контракт на поставку ресурсов требуемого качества на конкретное время с владельцами ресурсных пулов. Отличие от предыдущего варианта — все прочерки заменены на реальные имена и фамилии.
  
  
• Стафинг — процесс подбора и согласование ресурсов на незастафленные позиции ресурсного плана. Проще говоря, стафинг — это подбор команды на проект. Тут важно отметить, что очень редко бывает, что руководитель проекта получает на свой проект сотрудников, полностью соответствующих сформулированным требованиям. Все хотят на проект команду, на 100% состоящих из сеньерных дизайнеров, разработчиков, аналитиков и тестировщиков, но не все получают такие команды. Также не всегда удается получить людей к нужному сроку или на нужное время. По-этому, план может видоизменяться по мере стафинга. Если качество ресурсов хуже того, которое закладывалось при оценке проекта, то, очевидно, увеличивается количество часов для выполнения тех же самых работ. Если нужный ресурс высвобождается с другого проекта раньше или позже, чем вы планировали, то вы фиксируете это обстоятельство и переделываете план уже с учетом новых условий.

Так чем же люди отличаются от денег?

Для лучшего понимания сути управления ресурсами проведем аналогию с управлением финансами:

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

В мире денег, если вы возьмете в банке в долг 100 000 рублей, вы сразу же сможете их начать тратить, инвестировать и т.п. — деньги сразу же начнут работать, их не нужно учить. В мире управления ресурсами, если вы возьмете “в долг” двух разработчиков, они, как правило, не могут сразу же начать приносить пользу вашему проекту. Потому что, в отличие от денег, ценность ресурса определяется не только его квалификацией и уровнем владения тем или иным инструментом, но и знанием специфики конкретно вашего проекта. А это знание можно приобрести только находясь внутри вашего проекта, потратив определенное время на его изучение.

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

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

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

https://habrahabr.ru/post/334984/

https://habrahabr.ru/post/334980/

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

Немного про способы отображения информации

Больше конкретики

Навигатор

Клиенты социальных сетей

ВКонтакте

Telegram

WhatsApp и Viber

Facebook и Facebook Messenger

Skype

WeChat

KakaoTalk

Браузеры

Администрирование и программирование

Текстовые редакторы

Итоги

https://habrahabr.ru/post/334982/

Что-то идет не так, хм.

• минус ~150 000 рублей
• понимание, что это довольно сложная область
• проверка правила Парето в действии
• собранная черновая информация по процессам

А если попытаться заработать на попытках?

• минус ~50 000 рублей
• плюс ~7 000 рублей
• 2 отправленных на ревью ассета
• убрана проблема с разделением работа-дом, бич фрилансеров
• возможность закопаться во все детали без больших убытков
• тщательный анализ
• веселые мозговые штурмы

Дальше?

https://habrahabr.ru/post/334976/

Сегодня мы дадим ответ на простой вопрос: "Как работает распределённое обучение (в контексте MXNet)?"

Все примеры кода протестированные на MXNet v0.10.0 и могут не работать (или работать по-другому) в других версиях, однако полагаю, что общие концепции будут неизменимы еще долго.

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

• Madan Jampani;
• Suneel Marthi;

Еще хотел бы порекомендовать поднять машинку с DLAMI и выполнить все примеры из статьи самостоятельно, тем более, что они достаточно простые. Для выполнения кода вполне себе подойдет бесплатная машинка на AWS.

С преамбулой окончено, лезем под кат...

Распределенное обучение каким MXNet его видит

В MXNet все участники процесса обучения поделены на 3 логические группы:

• планировщик (scheduler);
• сервер (server);
• рабочий (worker);

Это чисто логическое распределение, так что все участники могут работать на одной машине.

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

Планировщик

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

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

Сервер

Сервер выступает в качестве хранилища параметров модели обучения. То есть, если обучается модель в стиле: Y = AX + B, сервер хранит вектора A и B. Еще он отвечает за их корректное обновление. Серверов может быть более чем один, а соответственно есть правило, по которому модель распределяется на несколько серверов. Но это тема отдельной статьи.

Рабочий

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

Пример кластера

Давайте возьмем бутафорский пример кластера с:

• планировщиком на отдельной машине;
• двумя серверами;
• тремя машинами с рабочими;

Сам кластер будет выглядеть вот так:

Эта картинка, как и описанная конфигурация, будет использована только для визуализации потока данных.

Инициализация кластера

Мы не будем на практике создавать такой большой кластер как было описано выше, а обойдемся намного более маленьким кластером с 3-мя нодами на одной физической машине. Есть несколько тому причин:

• проще и дешевле;
• все логи будут в одном месте, что упростит объяснение;

Перед тем как продолжить, нужно уточнить одну деталь. Для MXNet, распределённое обучение по сути означает, что необходимо использовать KVStore. Имя это — акроним от "Key Value Storage". И по существу — это распределенное хранилище, которое выполняется на серверах и имеет некоторую дополнительную функциональность (например знает, как именно нужно обновлять модель, получив градиентный шаг от рабочего).

Также, поддержка KVStore доступна только в одном из двух вариантах:

• MXNet был собран вручную, с включенным флагом USE_DIST_KVSTORE=1 или
• был использован DLAMI (так как в нем фреймворк собран вручную с включенным флагом USE_DIST_KVSTORE=1)

В данной статье я предполагаю, что будет использован MXNet из релиза Jun/Jul DLAMI ( MXNet 0.10.0).
Еще есть не нулевая вероятность, что на момент прочтения, официальный pip пакет MXNet будет иметь поддержку KVStore.

Настало время начать создавать логических участников кластера. Чтобы создать участника достаточно лишь создать некоторые переменные среды и после заимпортировать модуль mxnet.

Планировщик

Первым делом запустим планировщик:

ubuntu:~$ python
>>> import subprocess
>>> import os
>>> scheduler_env = os.environ.copy()
>>> scheduler_env.update({
… "DMLC_ROLE": "scheduler",
… "DMLC_PS_ROOT_PORT": "9000",
… "DMLC_PS_ROOT_URI": "127.0.0.1",
… "DMLC_NUM_SERVER": "1",
… "DMLC_NUM_WORKER": "1",
… "PS_VERBOSE": "2"
… })
>>> subprocess.Popen("python -c ‘import mxnet’", shell=True, env=scheduler_env)

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

Начнем с рассмотрения DMLC_ROLE. Давайте посмотрим где именно она используется, а именно в пакете ps-lite. В соответствии с официальным README(в вольном переводе):

Легкая и эффективная реализация сервера для хранения параметров.
Ну а точное место, где переменная среды считывается вот тут (к слову все ссылки на конкретные коммиты).

val = CHECK_NOTNULL(Environment::Get()->find("DMLC_ROLE")); // here  
std::string role(val); 
is_worker_ = role == "worker"; 
is_server_ = role == "server"; 
is_scheduler_ = role == "scheduler"; // and later here
verbose_ = GetEnv("PS_VERBOSE", 0);

Думаю, не стоит быть С++ гуру, чтобы понять, что тут происходит. Логичиская роль нода определяется по строке в этой самой переменной "DMLC_ROLE". Забавно, но похоже тут нет проверки на то, что данная переменная содержит одно из разрешенных значений. Это, потенциально, может привести к интерестным проблемам.

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

scheduler_.hostname = std::string(CHECK_NOTNULL(Environment::Get()->find("DMLC_PS_ROOT_URI"))); 
scheduler_.port = atoi(CHECK_NOTNULL(Environment::Get()->find("DMLC_PS_ROOT_PORT"))); 
scheduler_.role = Node::SCHEDULER; 
scheduler_.id = kScheduler; 
is_scheduler_ = Postoffice::Get()->is_scheduler(); // here

Если быстро пробежаться далее по коду, чтобы посмотреть, что там происходит можно увидеть следующее интересное место:

// get my node info
if (is_scheduler_) { 
  my_node_ = scheduler_; 
} else { 
  auto role = is_scheduler_ ?
     Node::SCHEDULER :
     (Postoffice::Get()->is_worker() ? Node::WORKER : Node::SERVER);

В этом конкретном примере переменная "role" никогда не будет равна Node::SCHEDULER. Так что у вас есть шанс создать pull-request, чтобы это поправить (если еще никто этого не сделал).

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

Идем далее, параметр: DMLC_PS_ROOT_PORT. С этим мы быстро разберемся с учетом уже имеющихся знаний. Вот код, который уже видели:

scheduler_.hostname = std::string(CHECK_NOTNULL(Environment::Get()->find("DMLC_PS_ROOT_URI"))); 
scheduler_.port = atoi(CHECK_NOTNULL(Environment::Get()->find("DMLC_PS_ROOT_PORT"))); // here
scheduler_.role = Node::SCHEDULER; 
scheduler_.id = kScheduler; 
is_scheduler_ = Postoffice::Get()->is_scheduler();

Вновь, это из van.cc. Как не трудно догадаться, это порт, на котором планировщик должен слушать сообщения.

Надеюсь на этом этапе понятно, что DMLC_PS_ROOT_URI это просто ip адрес планировщика. Так что давайте сразу прыгнем к обсуждению DMLC_NUM_SERVER и DMLC_NUM_WORKER.

Так сложилось, что каждый логический нод MXNet в кластере должен знать о всех других нодах. Так что для каждого нода, перед тем как он запустился, в переменных среды записывается как много в кластере рабочих и серверов (число планировщиков ненужно, ибо это всегда 1). К слову эта информация хранится в классе Postoffice (вместе с другой информацией о кластере).

Ну и последний параметр, но пожалуй один из архи-главнейших — PS_VERBOSE. Это заставит наш новосозданный процесс выводить отладочную информацию, что жизненно важно для нас сейчас.

С точки зрения нашей бутафорской диаграммы наш кластер выглядит сейчас как-то так:

Запускаем сервер

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

>>> server_env = os.environ.copy()
>>> server_env.update({
… "DMLC_ROLE": "server",
… "DMLC_PS_ROOT_URI": "127.0.0.1",
… "DMLC_PS_ROOT_PORT": "9000",
… "DMLC_NUM_SERVER": "1",
… "DMLC_NUM_WORKER": "1",
… "PS_VERBOSE": "2"
… })
>>> subprocess.Popen(“python -c ‘import mxnet’”, shell=True, env=server_env)

Надеюсь теперь происходящее в коде не вызывает вопросов, но на всякий случай:

• мы говорим, что новый процесс — сервер (DMLC_ROLE);
• мы говорим какой IP у планировщика (DMLC_PS_ROOT_URI);
• мы говорим на каком порту планировщик слушает входящее соединения (DMLC_PS_ROOT_PORT);
• мы говорим серверу как много рабочих в кластере (DMLC_NUM_WORKER)
• мы говорим серверу как много серверов в кластере (DMLC_NUM_SERVER)
• ну и устанавливаем вывод в режим отладки (2)

Тут кто-то может спросить: погодите, я думал что DMLC_PS_ROOT_PORT и DMLC_PS_ROOT_URI для указания IP и порта логического нода, который мы запускаем? Ответом будет — нет, это адрес и порт планировщика, а вот все остальные должны сами разобраться какой у них адрес и найти себе доступный порт в системе. Информация о планировщике им нужна, чтобы постучаться к нему и попросить, чтобы он добавил их в кластер.

После запуска серверов наша диаграмма выглядит вот так:

Запускаем рабочего

Настало время запустить, собственно, самого рабочего и создать KVStore:

>>> os.environ.update({
… "DMLC_ROLE": "worker",
… "DMLC_PS_ROOT_URI": "127.0.0.1",
… "DMLC_PS_ROOT_PORT": "9000",
… "DMLC_NUM_SERVER": "1",
… "DMLC_NUM_WORKER": "1",
… "PS_VERBOSE": "2"
… })
>>> worker_env = os.environ.copy() 
>>> import mxnet
>>> kv_store = mxnet.kv.create(‘dist_async’)

К слову, KVStore может работать в двух режимах:

• dist_sync
• dist_async

Я оставлю за пытливым читателем вопрос о том, чем эти режимы отличаются, об этом можно почитать вот тут.

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

Жизненный цикл ноды (Van)

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

• Start — запуск
• Stop — остановка
• Receiving — получение сообщения

Так же, тот самый класс (Van), что отвечает за обработку этих событий, имеет несколько других, не менее важных методов. О части из них мы поговорим детально позже в других статьях, а сейчас просто перечислим:

• Send — отправляет сообщение
• PackMeta — конвертирует модель в proto сообщение
• UnpackMeta — распаковывает proto сообщение и создает модель
• HeartBeat — посылает сообщение, что он еще жив

Вот что выполняет каждая нода в момент, когда приходит сигнал Start:

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

Инициализация кластера

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

[00:33:12] src/van.cc:75: Bind to role=worker, ip=1.1.1.1, port=37350, is_recovery=0

Это запускается процесс рабочего. В данном случае это метод Start, который сообщает нам, что его адрес 1.1.1.1, роль "worker" и порт, который он нашел 37350. Теперь он моментально попробует уведомить планировщик, что он готов быть добавлен в кластер, указав свой адрес и порт:

[00:33:12] src/van.cc:136:? => 1. Meta: request=0, timestamp=3, control={ cmd=ADD_NODE, node={ role=worker, ip=1.1.1.1, port=37350, is_recovery=0 } }

Это конкретное сообщение сгенерировано в методе Send, вот тут. В нем нужно обратить внимание на несколько вещей:

• is_recovery=0 — сообщает, что он не в режиме восстановления, эта часть выходит за рамки данной статьи
• cmd=ADD_NODE — команда планировщику добавить рабочего в кластер
• ? => 1 — у каждого нода есть свой ранг. Ранг назначаеться планировщиком. Сам планировщик имеет ранг 1. В нашем случае нода без ранга отправляет сообщение ноде с рангом 1(планировщик).

На нашей диаграмме этот обмен сообщениями выглядит следующим образом:

Идем далее

[00:33:13] src/van.cc:75: Bind to role=server, ip=2.2.2.2, port=54160, is_recovery=0

Это проснулся наш сервер. Нашел себе порт (54160) и тут же пытается уведомить об этом планировщик:

[00:33:13] src/van.cc:136:? => 1. Meta: request=0, timestamp=0, control={ cmd=ADD_NODE, node={ role=server, ip=2.2.2.2, port=54160, is_recovery=0 } }

На диаграмме это выглядит вот так:

Так же, как и в случае с рабочим, наш сервер отправляет команду "ADD_NODE", чтобы его зарегистрировали в кластере. Так, как сервер еще не зарегистрирован в кластере и не имеет ранга, то мы видим: "? => 1".

[00:33:13] src/van.cc:75: Bind to role=scheduler, id=1, ip=127.0.0.1, port=9000, is_recovery=0

Наконец то планировщик запущен. Он использует локальный IP и порт 9000 (все ноды в кластере должны уже знать об его адресе и порте). Так как планировщик поднят, то логично ожидать, что в этот момент он получит все входящие сообщения, что были ему отправлены и… вуаля:

[00:33:13] src/van.cc:161:? => 1. Meta: request=0, timestamp=0, control={ cmd=ADD_NODE, node={ role=server, ip=2.2.2.2, port=54160, is_recovery=0 } }

Сообщение от сервера. Эта часть логов сгенерирована методом Receive, если быть еще более точным то вот тут. Тут же планировщик получает второе сообщение, на этот раз от рабочего:

[00:33:13] src/van.cc:161:? => 1. Meta: request=0, timestamp=3, control={ cmd=ADD_NODE, node={ role=worker, ip=1.1.1.1, port=37350, is_recovery=0 } }

Первым делом планировщик берется назначать ранги, вначале рабочему (9):

[00:33:13] src/van.cc:235: assign rank=9 to node role=worker, ip=1.1.1.1, port=37350, is_recovery=0

Теперь серверу (8):

[00:33:13] src/van.cc:235: assign rank=8 to node role=server, ip=2.2.2.2, port=54160, is_recovery=0

После идет довольно важная часть:

[00:33:13] src/van.cc:136:? => 9. Meta: request=0, timestamp=0, control={ cmd=ADD_NODE, node={ role=worker, id=9, ip=1.1.1.1, port=37350, is_recovery=0 role=server, id=8, ip=2.2.2.2, port=54160, is_recovery=0 role=scheduler, id=1, ip=127.0.0.1, port=9000, is_recovery=0 } }

Сообщения вроде этих показывают, что планировщик получил команды "ADD_NODE" от всех, нод кластера (в нашем случае от 1го рабочего и 1го сервера) и теперь начал уведомлять все ноды обратно о их рангах и об информации о всех других нодах в кластере. То есть планировщик отправляет ВСЮ информацию о КАЖДОМ ноде кластера КАЖДОМУ ноду кластера.

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

На диаграмме этот процесс выглядит вот так:

Следующий вывод:

[00:33:13] src/van.cc:136:? => 8. Meta: request=0, timestamp=1, control={ cmd=ADD_NODE, node={ role=worker, id=9, ip=1.1.1.1, port=37350, is_recovery=0 role=server, id=8, ip=2.2.2.2, port=54160, is_recovery=0 role=scheduler, id=1, ip=127.0.0.1, port=9000, is_recovery=0 } }

Такое же подтверждение планировщик отправляет ноде с рангом 8 (сервер). На диаграмме выглядит так:

[00:33:13] src/van.cc:251: the scheduler is connected to 1 workers and 1 servers

Планировщик радостно сообщил, что он подключён к одному рабочему и одному серверу (ко всем нодам кластера).

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

[00:33:13] src/van.cc:161: 1 => 2147483647. Meta: request=0, timestamp=0, control={ cmd=ADD_NODE, node={ role=worker, id=9, ip=1.1.1.1, port=37350, is_recovery=0 role=server, id=8, ip=2.2.2.2, port=54160, is_recovery=0 role=scheduler, id=1, ip=127.0.0.1, port=9000, is_recovery=0 } }
[00:33:13] src/van.cc:281: W[9] is connected to others

Это рабочий получил сообщения от планировщика и сообщает, что он подключен к кластеру. Можно спросить, а что такое "2147483647". Ответ — понятия не имею =) скорее всего бага, Я бы ожидал увидеть: "1 =>9". Так, как рабочий корректно видит свой ранг: "W[9]", баг скорее всего где-то в процессе логирования, так что можете его пофиксить и стать контрибьютором проекта.

[00:33:13] src/van.cc:161: 1 => 2147483647. Meta: request=0, timestamp=1, control={ cmd=ADD_NODE, node={ role=worker, id=9, ip=1.1.1.1, port=37350, is_recovery=0 role=server, id=8, ip=2.2.2.2, port=54160, is_recovery=0 role=scheduler, id=1, ip=127.0.0.1, port=9000, is_recovery=0 } }
[00:33:13] src/van.cc:281: S[8] is connected to others

Тоже самое для сервера: он получил сообщение и довольный поведал об этому миру.

[00:33:13] src/van.cc:136:? => 1. Meta: request=1, timestamp=4, control={ cmd=BARRIER, barrier_group=7 }
[00:33:13] src/van.cc:136:? => 1. Meta: request=1, timestamp=2, control={ cmd=BARRIER, barrier_group=7 }
[00:33:13] src/van.cc:136:? => 1. Meta: request=1, timestamp=1, control={ cmd=BARRIER, barrier_group=7 }

Еще одна важная часть. До сих пор мы видели только одну команду "ADD_NODE". Тут мы наблюдаем новую: "BARRIER". Если кратко, то эта концепция барьеров, которая, надеюсь, знакома читателю по многопоточному программированию и означает: "остановитесь до тех пор, пока все не дойдут до этого барьера". Планировщик отвечает за то, чтобы сообщить, когда именно все достигнут барьера и могут продолжать выполнение. Первый барьер расположен сразу после того, как кластер стартовал, но перед началом обучения. Все три ноды (включая сам планировщик) отправили сообщения, которое по существу значит: "я достиг барьера, дай мне знать, когда можно двигаться далее".

Так же, как видно из сообщения тут есть понятие барьерной группы(barrier_group). Барьерная группа эту группа нодов, которые участвуют в том или ином барьере. Эти группы:
1 — планировщик
2 — сервера
4 — рабочие

Как не трудно догадаться, это степень двойки, так что наша группа 7 это: 4 + 2 + 1. По существу данный барьер распространяется на всех.

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

[00:33:13] src/van.cc:161: 1 => 1. Meta: request=1, timestamp=2, control={ cmd=BARRIER, barrier_group=7 }
[00:33:13] src/van.cc:291: Barrier count for 7: 1
[00:33:13] src/van.cc:161: 9 => 1. Meta: request=1, timestamp=4, control={ cmd=BARRIER, barrier_group=7 }
[00:33:13] src/van.cc:291: Barrier count for 7: 2
[00:33:13] src/van.cc:161: 8 => 1. Meta: request=1, timestamp=1, control={ cmd=BARRIER, barrier_group=7 }
[00:33:13] src/van.cc:291: Barrier count for 7: 3

Происходящее на нашей диаграмме выглядит вот так:

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

• он увеличивает счетчик числа нодов, которые отправили команду BARRIER в определенной группе (вот тут)
• когда счетчик будет равен числу нодов в группе, он отправляет всем подтверждение о том, что можно продолжить нормальную работу

В логах выше можно увидеть, как счетчик увеличивался по мере получения каждого нового сообщения. Ну а в момент, когда он достиг ожидаемого размера (3), планировщик начал отправлять подтверждения:

[00:33:13] src/van.cc:136:? => 9. Meta: request=0, timestamp=3, control={ cmd=BARRIER, barrier_group=0 }
[00:33:13] src/van.cc:136:? => 8. Meta: request=0, timestamp=4, control={ cmd=BARRIER, barrier_group=0 }
[00:33:13] src/van.cc:136:? => 1. Meta: request=0, timestamp=5, control={ cmd=BARRIER, barrier_group=0 }

На нашей диаграмме это выглядит вот так:

Как можно заметить, планировщик даже отправляет подтверждение самому себе. Ну и само собой, раз было отправлено сообщение от планировщика (аж 3), то мы должны увидеть логи о том, что эти сообщения получены:

[00:33:13] src/van.cc:161: 1 => 9. Meta: request=0, timestamp=3, control={ cmd=BARRIER, barrier_group=0 }
[00:33:13] src/van.cc:161: 1 => 8. Meta: request=0, timestamp=4, control={ cmd=BARRIER, barrier_group=0 }
[00:33:13] src/van.cc:161: 1 => 1. Meta: request=0, timestamp=5, control={ cmd=BARRIER, barrier_group=0 }

Ну и последние прикосновения. В данный момент планировщик достиг второго барьера, который будет достигнут всеми нодами после окончания обучения, однако, так как планировщик не принимает участие в обучении, то он уже достиг этот самый барьер. Так что он отправляет группе barrier_group=7 что он достиг барьер, с мгновенным подтверждением получения сообщения и установкой счетчика барьерной группы 7 в 1.

[00:33:13] src/van.cc:136:? => 1. Meta: request=1, timestamp=6, control={ cmd=BARRIER, barrier_group=7 }
[00:33:13] src/van.cc:161: 1 => 1. Meta: request=1, timestamp=6, control={ cmd=BARRIER, barrier_group=7 }
[00:33:13] src/van.cc:291: Barrier count for 7: 1

На этом этапе инициализация кластера закончена, можно начать обучение...

Обучение

Выполнив весь код, мы имеем инициализированный KVstore. Что же теперь? Давайте используем его для непосредственного обучения. Я воспользуюсь очень простым примером линейного регрессора взятого вот от сюда. Только прошу, перед тем, как продолжить, пройдитесь по примеру, чтобы понять происходящее. Что бы сделать тренировку в описанном примере распределенной, нужно поменять всего 1 линию в коде. Вместо:

model.fit(train_iter, eval_iter,
            optimizer_params={
                'learning_rate':0.005, 'momentum': 0.9},
            num_epoch=50,
            eval_metric='mse',
            batch_end_callback
                 = mx.callback.Speedometer(batch_size, 2))

Нужно написать:

model.fit(train_iter, eval_iter,
            optimizer_params={
                'learning_rate':0.005, 'momentum': 0.9},
            num_epoch=50,
            eval_metric='mse',
            batch_end_callback
                 = mx.callback.Speedometer(batch_size, 2),
            kvstore=kv_store) # updated line

Так просто? если коротко — да.

Небольшое заключение

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

• планировщику не критично меть быстрое соединение с остальными
• серверам не критично иметь быстрое соединении между собой
• каждый рабочий должен иметь быстрое соединение с каждым сервером
• рабочим не критично иметь быстрое соединение с друг другом

Буду очень благодарен за рекомендации оригинальной статьи на Medium. Так же, если вдруг вы занимаетесь построением распределённых систем машинного обучения на базе AWS с использованием MXNet и у вас есть какие либо вопросы, то я с радостью готов помочь и ответить (viacheslav@kovalevskyi.com).

Ссылки:

• полная версия кода из статьи
• Draw.IO, сервис для рисования диаграм
• MXNet ps-lite репозиторий

https://habrahabr.ru/post/334968/

Взлом маршрутизаторов WPA/WPA2 Wi-Fi с помощью Airodump-ng и Aircrack-ng/Hashcat

Для начала

• В целом не испытываете проблем с использованием командной строки.
• Работаете в дистрибутиве Linux на базе Debian, желательно Kali linux (пользователям OS X см. приложение).
• У вас установлен Aircrack-ng
  
  • sudo apt-get install aircrack-ng
• Ваша карта беспроводной связи поддерживает режим монитора (см. список совместимых устройств).

Взлом сети Wi-Fi

Режим монитора

Найти цель

CH 13 ][ Elapsed: 52 s ][ 2017-07-23 15:49                                         
                                                                                                                                              
 BSSID              PWR  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID
                                                                                                                                              
 14:91:82:F7:52:EB  -66      205       26    0   1  54e  OPN              belkin.2e8.guests
 14:91:82:F7:52:E8  -64      212       56    0   1  54e  WPA2 CCMP   PSK  belkin.2e8
 14:22:DB:1A:DB:64  -81       44        7    0   1  54   WPA2 CCMP        
 14:22:DB:1A:DB:66  -83       48        0    0   1  54e. WPA2 CCMP   PSK  steveserro
 9C:5C:8E:C9:AB:C0  -81       19        0    0   3  54e  WPA2 CCMP   PSK  hackme
 00:23:69:AD:AF:94  -82      350        4    0   1  54e  WPA2 CCMP   PSK  Kaitlin's Awesome
 06:26:BB:75:ED:69  -84      232        0    0   1  54e. WPA2 CCMP   PSK  HH2
 78:71:9C:99:67:D0  -82      339        0    0   1  54e. WPA2 CCMP   PSK  ARRIS-67D2
 9C:34:26:9F:2E:E8  -85       40        0    0   1  54e. WPA2 CCMP   PSK  Comcast_2EEA-EXT
 BC:EE:7B:8F:48:28  -85      119       10    0   1  54e  WPA2 CCMP   PSK  root
 EC:1A:59:36:AD:CA  -86      210       28    0   1  54e  WPA2 CCMP   PSK  belkin.dca

Захват 4-стороннего рукопожатия

 CH  6 ][ Elapsed: 1 min ][ 2017-07-23 16:09 ]

 BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID

 9C:5C:8E:C9:AB:C0  -47   0      140        0    0   6  54e  WPA2 CCMP   PSK  ASUS

Взлом пароля сети

                                 Aircrack-ng 1.2 beta3


                   [00:01:49] 111040 keys tested (1017.96 k/s)


                         KEY FOUND! [ hacktheplanet ]


      Master Key     : A1 90 16 62 6C B3 E2 DB BB D1 79 CB 75 D2 C7 89 
                       59 4A C9 04 67 10 66 C5 97 83 7B C3 DA 6C 29 2E 

      Transient Key  : CB 5A F8 CE 62 B2 1B F7 6F 50 C0 25 62 E9 5D 71 
                       2F 1A 26 34 DD 9F 61 F7 68 85 CC BC 0F 88 88 73 
                       6F CB 3F CC 06 0C 06 08 ED DF EC 3C D3 42 5D 78 
                       8D EC 0C EA D2 BC 8A E2 D7 D3 A2 7F 9F 1A D3 21 

      EAPOL HMAC     : 9F C6 51 57 D3 FA 99 11 9D 17 12 BA B6 DB 06 B4

Атака с деаутентификацией

 CH  6 ][ Elapsed: 2 mins ][ 2017-07-23 19:15 ]
                                                                                                                                           
 BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID
                                                                                                                                           
 9C:5C:8E:C9:AB:C0  -19  75     1043      144   10   6  54e  WPA2 CCMP   PSK  ASUS
                                                                                                                                           
 BSSID              STATION            PWR   Rate    Lost    Frames  Probe
                                                                                                                                           
 9C:5C:8E:C9:AB:C0  64:BC:0C:48:97:F7  -37    1e- 1e     4     6479  ASUS

Список команд

Приложение

• Перехватывать рукопожатия и взламывать пароли WPA на MacOS/OSX
• Перехватывать рукопожатия со всех сетей вокруг с помощью wlandump-ng
• Использовать crunch для генерации на лету словарных списков на 100 ГБ и больше
• Подделывать свой MAC-адрес с помощью macchanger

Авторство

https://habrahabr.ru/post/334966/

import grequests 
with open("C:\\path\\urls.txt") as werewolves: 
    array = [row.strip() for row in werewolves]

params = {'a':'b', 'c':'d'}
rs = [grequests.post(u, data=params) for u in array]
for r in grequests.imap(rs, size=16) 
    print(r[0].status_code, r[0].url)

def exception_handlerr(request, exception):
    print("Request failed", request.url) 

import grequests 
with open("C:\\path\\urls.txt") as werewolves: 
    array = [row.strip() for row in werewolves]

params = {'a':'b', 'c':'d'}
rs = [grequests.post(u, data=params) for u in array]
for r in grequests.map([rs], size=16, exception_handler=exception_handlerr) 
    print(r[0].status_code, r[0].url)

def send(self, **kwargs):
    """
    Prepares request based on parameter passed to constructor and optional      ``kwargs```.
    Then sends request and saves response to :attr:`response`

    :returns: ``Response``
    """
    merged_kwargs = {}
    merged_kwargs.update(self.kwargs)
    merged_kwargs.update(kwargs)
    try:
        self.response = self.session.request(self.method,
                                            self.url, **merged_kwargs)
    except Exception as e:
        self.exception = e
        self.traceback = traceback.format_exc()
    return self

def exception_handlerr(request, exception):
    print("Request failed", request.url) 
    # print(str(exception)) 

def exception_handlerr(request, exception):
    print("Request failed", request.url) 

import grequests 
with open("C:\\path\\urls.txt") as werewolves: 
    array = [row.strip() for row in werewolves]

params = {'a':'b', 'c':'d'}
rs = [grequests.post(u, data=params) for u in array]
for r in grequests.map([rs], size=16, exception_handler=exception_handlerr) 
    print(r.status_code, r.url)

def exception_handlerr(request, exception):
    print("Request failed", request.url) 

import grequests 
with open("C:\\path\\urls.txt") as werewolves: 
    array = [row.strip() for row in werewolves]

params = {'a':'b', 'c':'d'}
rs = [grequests.get(u) for u in array]
for r in grequests.map([rs], size=16, exception_handler=exception_handlerr) 
    print(r.status_code, r.url)

https://habrahabr.ru/post/334970/

Дорогой JavaScript-разработчик!

0 уровень: «jQuery — хороший»

https://habrahabr.ru/post/334964/

Как работает Android, часть 1

• (+3) AppCode 2017.2: Extract Method и улучшения автодополнения для Swift, поддержка __auto_type в Objective-C и многое другое
• (+2) Кейс iOS приложения BINO CX: Uber для управления потребительским опытом
• iPhone 8 и iOS 11
• Apple против PWA: Ущерб будущему веба
• Улучшение iOS-симулятора
• Используем ARKit с Metal
• Топ-5 iOS-библиотека Августа
• В TestFlight теперь доступно 10,000 пользователей
• Держите вещи сухими… и пишите меньше кода с протоколами Swift
• Анимация бокового меню
• SQLite.viewer: просмотр, редактирование и отладка sqlite баз

• (+21) Математический пакет для Android — «Микро-Математика» — теперь с открытым исходным кодом
• (+20) Не пропустите крупнейшее мероприятие Google для разработчиков в Европе
• (+17) Android O: особенности поддержки новой операционной системы
• (+13) Dagger 2. Subcomponents. Best practice
• (+4) В разрезе: новостной агрегатор на Android с бэкендом. Система сборки, Система контроля версий и Вводная часть, идея, технологии
• (+2) Android Architecture Components. Часть 4. ViewModel
• Google понизит некачественные приложения
• Firebase на Android: исследуем динамические ссылки
• Firebase Meetup №4: Google Analytics for Firebase: 17 августа в Москве
• Google запустил Nearby Connections 2.0
• Структурный поиск и замена в Android Studio
• Анимация ItemDecoration в RecyclerView
• Дело против Kotlin
• Эффективная загрузка больших картинок на Android
• Как выучить Android-разработку
• Введение в физическую анимацию в Android
• Плавные анимации переходов для Android
• Шпаргалка по RxJava
• Топ-5 Android-библиотек августа
• Обработка ошибок в RxJava
• Практические советы по миграции вашего Android-приложения на Kotlin
• AnyMaps: один API для Google Maps, OpenStreet maps, Baidu
• UberUX: анимационный стек Uber
• Android Translator: быстрый перевод приложений
• AutoplayVideos: автоплей видео по URL в RecyclerView

• Новое видение Microsoft: mobile-first уходит, приходит AI-first

• (+29) Дизайнер интерфейсов: Первая специализация Mail.Ru Group на Coursera
• (+19) Разработка под Sailfish OS глазами iOS-разработчика
• (+19) Обзор Lokalise — сервиса для локализации приложений и обновления переводов «по воздуху»
• (+17) Лагерная игра «Мафия» на 50+ человек
• (+16) Лицензирование музыки для инди-разработчиков
• (+13) Как попытаться сделать пользователю удобно и кое-что запороть в процессе
• (+3) Как мы оптимизировали Ragdoll анимацию смерти в Unity
• Agora.io выпускает SDK для голосовых чатов
• Plume API предсказывает загрязнение воздуха
• Я идиот: стратегия успешного идиотизма в разработке
• Fitbit запустит свою платформу приложений
• Победители Imagine Cup 2017
• Время сделать код более открытым для изменений
• Искусство партизанского пользовательского тестирования
• Закладки продуктового дизайнера
• Что такое выгорание программиста
• Самый важный цвет в UI
• NVIDIA анонсирует AI SDK
• Как дизайнеры Google адаптируют материальный дизайн
• Создание масштабируемых, изолированных мобильных функций с помощью плагинов в Uber

• (+14) Олег Дорожок (Delivery Club) о маркетинге, мобильном ретаргетинге, покупке ZakaZaka и випассане
• (+6) Аналитические системы для мобильных приложений: тест и критерии выбора
• Tapjoy: Вознаграждающая реклама увеличивает покупки в 4.5 раза
• Прогноз для индустрии приложений: рынок объемом в $6 трлн
• Кейс Qmobi: публикация приложения Jetradar в Китае
• Мобильная монетизация и вовлечение пользователей: исследование AdColony
• 12 сетей с вознаграждающим видео
• Руководство по категориям магазинов

• (+20) Поиграем в Firebase
• (+9) Охота на рыжего демона или пеленгатор помех спутниковой навигации
• ASUS ZenFone AR с поддержкой Project Tango и Daydream
• Дайджест интернета вещей: Июль 2017

https://habrahabr.ru/post/334958/

Лирическое отступление

Всем доброго времени суток!

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

Хочу рассказать о том, как начала создаваться наша молодая indie студия и какие выводы мы для себя почерпнули.

Коротко о нас и как так вышло

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

Вариантов была масса, все они были тщательно проработаны и собраны небольшие бизнес планы.
Решили остановиться на области game dev. Хочу, чтобы вы понимали правильно, что в этой области действительно есть как свои огромные перспективы и шансы, так и огромные риски потерять много времени, денег, сил и при этом не получить ничего взамен. Об историях успехов и падений написано много, так что мы опустим эти моменты.

Начало работы

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

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

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

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

1. Анализ рынка;
2. Выбор платформы;
3. Выбор механики;
4. Выбор движка под механику;
5. Написание концепций;
6. Подготовка материалов;
7. Начало разработки.

Анализ рынка и выбор платформы

На данный момент ежегодный рост рынка мобильных игр и приложений близится к 30%, при этом игры для ПК и консолей такими показателями похвастаться не могут.

Безусловным фаворитом для нас стали мобильные платформы Android и iOS. Разработка решили вести на обе платформы и руководствовались такой логикой, что выпускать продукт для рынка России и бывших стран СНГ (где преобладает Android) не на столько интересно, как для стран Европы, Азии (Китай и Япония) ну и конечно же США. Аудитория, которая пользуется выбранными платформами в этих странах разделилась практически поровну.

Выбор механики

Скажем так: топы по скачиваниям и сборам — MMO и фермы, но для молодой студии это слишком долго и дорого. На втором месте — казуалки формата 2048 и три в ряд, но ниша очень переполнена такими приложениями и занять в ней достойное место будет сложно. Дальше мы увидели, что ранеры subway surfers, temple run и им подобные имеют огромное количество скачиваний, находятся в топах по популярности но не имеют отметок по топовости сборов.

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

Выбор движка

Тут всё было максимально и просто. Выбрали unity3d из за относительной простоты разработки и портирования на разные устройства.

Написание концепций

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

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

Подготовка материалов

Далее были собраны кейсы успешных игр, которые отличились визуальной составляющей и атмосферой. По референсам была поставлена задача иллюстраторам и программистам.
Были сделаны первые скетчи и собран небольшой уровень без графических элементов (набор кружочков и квадратиков). Дальше работу программистов, гейм дизайнера и иллюстраторов нужно было поставить на поток и стандартизировать. Мы использовали Google docs в качестве площадки для диз.доков, Trello для таск трекинга и Telegram для корпоративного общения. Для небольшой команды использовать Jira или Bitrix24 по нашему скромному мнению не имеет смысла.

Начало разработки

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

P.S.

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

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

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

To be continued...

https://habrahabr.ru/post/334956/

Чек-листы vs Тест-кейсы

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

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

Таблицы vs Деревья

• структура такой документации в итоге очень гибкая и позволяет вести как чек-листы, так и тест-кейсы в зависимости от нужд проекта
• дерево представляется в виде вложенных списков: у узлов дерева есть некоторый порядок, что сохраняет возможность последовательной и структурированной передачи информации о требованиях тестировщику в случае отсутствия на проекте задокументированного ТЗ
• такая структура позволяет спроектировать тестовую документацию, которую можно передать разработчикам вместо ТЗ
• временные затраты на написание чек-листов и тест-кейсов снижаются, поскольку структура позволяет избежать копипасты

• такая структура тестовой документации требует тщательного проектирования и предварительной аналитики — при плохом проектировании все упомянутые выше плюсы теряются

Итоговые паттерны

Экраны приложения

• UI является приоритетным для заказчика
• минимум бизнес-логики на клиенте
• для приложения характерны кастомные элементы дизайна и анимации, сложные жесты
• на проекте нет других задокументированных требований кроме навсхемы

Объекты/действия

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

На базе Use cases

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

Отталкиваемся от цели

https://habrahabr.ru/post/334660/

Введение

Пушки для DOOM

Продакшен

Перспектива и поворот камеры

Визуальные эффекты и анимация

Работа в 3ds Max и MODO

Текстурирование 3D Coat

Механика

https://habrahabr.ru/post/334874/

Соберите информацию о компании

• Резюме и технические блоги работающих или ранее работавших в вашей будущей компании сотрудников; особенно ценную информацию можно собрать из LinkedIn’а, профильных форумов, публичных репозиториев исходных кодов ПО, иногда из корпоративных аккаунтов соцсетей; старайтесь не оставлять следов, пользуйтесь фейковыми аккаунтами для просмотра (особенно в LinkedIn’е).
  
  
• Информацию из личных блогов сотрудников, такую как класс и марка автомобилей, наличие недвижимости, места проведения досуга и отпуска, состав семьи – это даст информацию о классе дохода сотрудников; особенно интересна подобная информация о будущих нанимающих менеджерах, чьи имена не сложно получить у HR, спросив, кто будет проводить собеседования.
  
  
• Локальные форумы или крупные пользовательские группы могут дать отзывы о работодателе, но относитесь к полученной там информации с долей скептицизма.
  
  
• Опубликованные в прессе интервью работников и аналитику маркетинговых и новостных агентств (напр. РБК/CNews/Gartner).
  
  
• Просканируйте сети и адреса компании, изучите заголовки e-mail’ов, полученных от HR; если вы web-разработчик, то вам может быть полезно знать фреймворки, используемые на веб-сервисах компании; если вы сетевой администратор, то вас будут интересовать детали BGP пиринга, whois, и WiFi с порталом самообслуживания в холле; для системных администраторов интересны служебные заголовки опубликованных сервисов.
  
  
• Ранее открывавшиеся вакансии этой компании (напр. google://site:hh.ru/vacancy/ «Вакансия в архиве» название_компании) – один из самых ценных источников информации об используемых технологиях и текущих проектах.
  
  
• Изучите доступную документацию тендеров – она часто содержит подробные описания проектов, в которых компания была заказчиком, или исполнителем.
  
  
• Просмотрите патенты и лицензии, полученные компанией, а также информацию о партнёрах.

Собеседование

Работа с отказами

После получения предложения

https://habrahabr.ru/post/334954/

whoami?

Permissions Denied: пути обхода

Болезни — как обратная связь

https://habrahabr.ru/post/334950/

• Построим контроллер, с интерфейсом Gigabit ethernet на ПЛИС
• То же, но на какой-то штуке (к примеру, AX88180)
• Ваш вариант

1. Выбор компьютера

   Одноплатные компьютеры пока брать не хотелось, т.к. не везде есть USB 3.0, не в каждом Gigabit Ethernet, который может вдруг понадобиться, да и реальная производительность таких плат — вопрос. Взял решение в коробочке с процессором Intel, крайне похожее на nuc: HDD 500Gb, RAM 2Gb, USB 3.0, Ethernet 100/1000. Не думаю, что это принципиальный вопрос.
   
2. Ставим Ubuntu Server

   Идем cюда. Качаем последнюю версию с надписью LTS, что означает долгосрочную поддержку и выход обновлений до 5 лет.
   У меня был Ubuntu Server 16.04.2.
   Ставим на пк с флэшки. Для этого: инструкция, как ставить на флэшку загрузочный образ, и инструкция, как ставить ОС.
   Не забудьте при установке поставить галочку OpenSSH server, для доступа по сети к компьютеру. Будем передавать файлы и управлять компьютером с помощью утилит из Putty.
   
3. Настраиваем и дополняем сервер

   Помимо непосредственного контакта с контроллером, требуется создать экосистему, позволяющую компилировать проект (мне показалось удобным это делать на прототипе, а не на рабочей машине с кросс компиляцией), выделять IP адрес для управляющего компьютера пользователя. Самый удобный вариант установки дополнительных пакетов — использование онлайн хранилища deb пакетов, доступного через apt-get, что работает при подключении к интернету. К счастью, это не единственный вариант установки. Если хочется не зависеть от интернета и каких-то изменений в библиотеках и пакетах, то можно выкачать нужные пакеты и устанавливать их самому с помощью:
   
   

   sudo dpkg -i <имя_пакета>.deb

   
   Но для этого нужно знать все зависимости. К примеру, установка isc-dhcp-server потянула у меня следующие пакеты:
   
   — libisccfg-export140
   — libirs-export141
   — isc-dhcp-server_4.3.3
   
   Для начала, подключаем к интернету сервер через маршрутизатор, который ему выделит IP (если что ищите в поисковике настройки файла /etc/network/interfaces ), и делаем следующее:
   
   Установка компилятора
   Примеры драйверов FTD3XX от FTDI написаны на C++11. Можно ставить компилятор g++, а при компиляции нужно будет указать опцию -std=c++11
   

   sudo apt-get install g++

   
   
   Вводим пароль и соглашаемся.
   
   Теперь в папке, где есть правильный Makefile можно написать

   make

   и будет компилироваться проект, но об этом позже.
   
   Установка DHCP сервера
   Я использовал isc-dhcp-server. На ubunte пишем:
   

   sudo apt-get install isc-dhcp-server

   
   Вводим пароль и соглашаемся.
   
4. Ставим драйвер от FTDI
5. Компилируем программу
6. Делаем демона для автозагрузки и слежения за программой
7. Контролируем процессы

https://habrahabr.ru/post/334948/