Она еще должна работать предсказуемо, и не валить в случае сбоя за собой всю систему.
… в тех сценариях, для которых она (программа) предназначена. И только в них. Если вы пишите тулу, которая запустится пару десятков раз, да еще и из ваших рук, прорабатывать все exceptional scenarions не имеет никакого смысла. Особенно если это негативно сказывается на скорости выполнения.
А с другой стороны, если у меня в программе невозможно выйти за пределы массива by design, зачем это каждый раз это проверять?
Потому что это правило хорошего дизайна программы.
Правило хорошего дизайна программы — делать ровно то, что необходимо для выполнения задачи.
Так что — экономия на спичках.
Неужели? Тогда объясните, пожалуйста, почему на банальном цикле и сложении, код на C++ оказывается в 100 раз быстрее кода на Python. И на этот раз попрошу пруфы от вас, если у вас есть контр-аргументы:
#!/bin/env python
import timeit
start = timeit.default_timer()
i_max = 100000000
i_print_div = i_max / 100
i = 0
while i < i_max:
if i % i_print_div == 0:
print(i, end='\r')
i = i + 1
print(i)
stop = timeit.default_timer()
print("Execution time: {} milliseconds".format((stop - start) * 1000) )
test.cpp:
#include<iostream>
#include <chrono>
using namespace std;
using namespace std::chrono;
int main()
{
auto start = high_resolution_clock::now();
const unsigned long int i_max = 100000000;
const unsigned long int i_print_div = i_max / 100;
unsigned long int i;
for (i = 0; i < i_max; i++)
if (i % i_print_div == 0)
cout << i << "\r" << flush;
cout << i << endl;
auto stop = high_resolution_clock::now();
auto duration = duration_cast<milliseconds>(stop - start);
cout << "Execution time: " << duration.count() << " milliseconds" << endl;
return 0;
}
Да, с одной стороны это возможность выстрелить себе в ногу. А с другой стороны, если у меня в программе невозможно выйти за пределы массива by design, зачем это каждый раз это проверять? В большинстве случаев это не мешает, но когда обрабатываются большие объемы данных, и важна производительность, это может сыграть роль. И это только один из примеров.
Кстати, в C++ тоже можно писать так, чтобы библиотека автоматически делала проверку. Следующий код на C++ завершится исключением:
Если Питон использовать по уму с модулями типа numpy то никакого драматического снижения производительности нет
Если С++ использовать по уму, то выстрелов в ногу тоже не будет.
Суть в том, что программист высокого уровня (обученный и с опытом) может написать как быструю программу на Python, так и безопасную программу на C++. А значит, выбор языка будет определяться другими факторами: конкретным сценарием / use case'ом, практиками принятыми в организации и т. п. Преимуществом языков с автоматизацией управления памятью, дополнительными проверками, прозрачной конвертацией типов и т. п. состоит в том, что человек с нуля может уже через небольшое время начать писать программы, которые будут работать. Если же есть возможность нанять человека уже со значительным опытом, то это преимущество нивелируется.
Потому что они позволяют меньше стрелять в ногу и быстрее получать результат?
Да, именно поэтому. Они делают 1000 проверок там, где достаточно 10. Соответственно, приходится выбирать: либо написать программу быстро, либо написать быструю программу.
Потому что, наверное, нормальных исключений нет?
Что ты понимаешь под «нормальными исключениями», и где по твоему мнению их нет?
Gentoo — source-based дистрибутив. И подходит он для соотв. задач — см. ниже.
И какие из этих задач решает лучше чем другие?
А альтернатив не так уж и много.
В отличии от LFS у Gentoo пакетный менеджер, системные утилиты, конфигурации и всё то, что позволяет использовать Gentoo как полноценный основной дистрибутив, даже для десктопа. LFS такого не позволяет.
Calculate — по сути бинарный вариант Gentoo; при том, как только мы хотим использовать фичи source-based дистрибутива, он превращается в Gentoo.
Не могу сказать, что хорошо знаю остальные source-based дистрибутивы, но знаю, что у Gentoo отличная документация (по опросам лучше только у Arch Linux), великолепный пакетный менеджер (единственный минус — медленный), много софта в репозитории. Ну, и Gentoo постоянно развивается.
Теперь что касается задач.
Сначала скажу в каких случаях Gentoo не подходит или не является оптимальным выбором:
— Для задач, которые не выставляют специальных требований к дистрибутиву.
— Для задач, для которых уже есть соотв. дистрибутив, и он вас устраивает.
— Пользователям, которые недостаточно хорошо знают Линукс, и не стремятся эти знания получить: такие пользователи просто не смогут установить Gentoo, а если таки установят, потом намучаются с ней.
Иными словами, если вас всё устраивает в Ubuntu, SuSe, Red Hat, и т. п., или если вы новичок, то Gentoo вам не нужна.
Когда Gentoo подходит.
1. Работа с исходным кодом на уровне дистрибутива. Представим, компанию, бизнес которой опирается на безопасность. Это может быть государственная организация, крупная финансовая структура и т. п. Притом требования безопасности настолько высоки, что в некоторых случаях требуются свежайшие версии софта (live в терминологии Gentoo), возможно — аудит кода (и компания имеет соотв. специалистов), в течении часов — применения патчей для закрытия 0-day уязвимостей, а может и создание этих патчей и т. п. Gentoo здесь будет хорошим выбором, так как source-based: из репозитория загружаются исходники, компиляция осуществляется локально (естественно, для компании — на соотв. серверах); при этом есть спец. средства для работы с патчами. Реальные примеры: Gentoo на Нью-Йоркской фондовой бирже и в Национальном агентстве кибербезопасности Франции (ANSSI).
2. Специфичная архитектура. Gentoo только поддерживает ARM, MIPS, HPPA, PowerPC, Sparc и др. Если жизнь вас столкнула с такой архитектурой, и под нее нет соотв. дистрибутива, или дистрибутив чем-то вас не устраивает (например, свежестью софта в репозиториях), то Gentoo может оказаться хорошим выбором.
3. Оптимизация под конкретное железо. Представим крупного cloud service provider или другую компанию, у которой одной из основных статей расходов является IT инфраструктура. Улучшение эффективности даже на несколько процентов может вылиться в миллионы долларов экономии. А максимальной оптимизации можно добиться только компилируя софт под конкретную платформу.
4. Оптимизация с целью минимального потребления ресурсов. Очень актуально в связи с популяризацией IoT и контейнеризации. Например, CoreOS (правда ее уже купил Red Hat).
5. Создание нового дистрибутива. На самом деле это покрывает сценарии описанные выше, но может включать и вообще любого рода конфигурации и кастомизации. В Gentoo есть механизмы профилей (что позволяет комбинировать общие настройки со специфичными для данного хоста); это в дополнение к средствам управления репозиториями, утилитам создания бинарных пакетов и т. п. Да, это умеют и другие дистрибутивы; но, в Gentoo можно выбрать нужные версии ПО (ибо rolling-release), скомпилировать под конкретную платформу, наложить свои патчи, избавиться от лишних зависимостей (ибо source-based). И то, что получилось, распространять как дистрибутив. Не только как публичный, но и как закрытый для внутреннего пользования для какой-то корпорации. Реальные примеры: Chrome OS, тот самый что Google устанавливает на Chromebook. Ну и другие; но понятно, что информация приватных дистрибутивах компаний не особо публикуется.
И от кровавого энтерпрайса перейдем к домашнему использованию Gentoo.
6. Обучение Линукс. По сценариям вверху можно понять на какого уровня специалистов рассчитан Gentoo. А поэтому там нет графических инсталляторов и красивых окошечек для домохозяек — только командная строка и текстовые конфиги. Установить Gentoo, настроить ее до комфортного состояния, а потом еще и пользоваться ей новичок не сможет. А если захочет, то придется разобраться в основных принципах и инструментах Linux: командная строка, работа с разделами жесткого диска, сборка ядра, и т. п. Я лично имею опыт обучения Linux человека по Gentoo handbook: и опыт успешный, потому как после теории человек сразу на практике видит, как это используется и зачем это нужно. Да и я сам, признаться, когда первый раз устанавливал Gentoo, много нового узнал. Дистрибутив с wizard-based инсталлятором и графическими конфигурационными утилитами такого ее даст. Кроме того, Gentoo ставит перед тобой вопросы, на которые нужно дать осмысленный ответ: systemd vs openrc, alsa vs pulseaudio, dhcpcd vs dhclient, syslog vs rsyslog vs syslog-ng и т. п.
7. Порядок в системе. Это очень субъективный сценарий, но есть люди, которые очень любят порядок в системе: ничего лишнего не установлено, автоматически ничего не запускается такого, чего явно не просили, система что-то меняет только с разрешения пользователя. И при этом всё максимально автоматизировано, всё делается в пару нажатий клавиш. Я знаю потому, что я сам к таким отношусь. Да, такое можно сделать на других дистрибутивах; просто в других дистрибутивах ты будешь вырезать то, что не нужно, а в Gentoo ты устанавливаешь только то, что нужно, что как по мне, проще и логичней. Мне нравится, что Gentoo дает выбор альтернатив софта (примеры выше). Мне очень нравится, как Gentoo работает с конфигами: если конфиг должен поменяться (а при обновлении софта такое может потребоваться), то пакетный менеджер кладет его рядом и просит пользователя посмотреть и принять изменения и перенести свои настройки; а я еще настроил авто-патчинг конфигов, так что теперь у меня конфиги обновляются автоматически и при этом не перетирают мои настройки. USE флаги отсекают лишние зависимости. Set'ы позволяют мне сделать сетап, который я тиражирую на несколько компьютеров, при этом легко добавляя индивидуальность где это нужно. Ну, и обновления запускаются в пару нажатий клавиш и, опять же, идут так, как мне нужно. Я в свое время перепробовал Red Hat, Slackware, Suse, но Gentoo мне показался наиболее простым, понятным, а еще система не думает, что она умнее меня и лучше знает, что мне нужно.
Наверное, некоторые пункты достойны холивора. Но всё-таки, надеюсь, я дал ответ на вопрос.
Требования — это всё, что отражает потребности заказчика. Пользовательские истории это отлично делают, а значит это требования.
Автора статьи, возможно, смутило то, что пользовательские истории как правило не достаточно конкретные, чтобы можно было начинать разработку.
Есть несколько видов требований: бизнес требования (business requirements), требования заинтересованных сторон (stakeholder requirements), требования к решению (solution requirements). Функциональные требования (functional requirement) — это подкатегория требований к решению.
В процессе бизнес анализа, нужно понимать потребности бизнеса, потребности конкретных пользователей, и т. п., чтобы убедиться, что тот функционал, то решение, которое мы разрабатываем, это то, что нужно заказчику. Пользовательские истории выполняют эту функцию. В большинстве это не то, что сразу можно брать в разработку, это скорее промежуточный этап.
В контракте же нужно фиксировать требования, с одной стороны, не очень детально, чтобы у разработчиков была возможность для маневров, а с другой стороны — достаточно детально, чтобы нельзя было позже раздуть объем работ. Это на грани искусства, но любой опытный бизнес-аналитик должен быть способен это сделать. Некоторые пользовательские истории удовлетворяют этим требования, и могут быть использованы в контракте.
Из IIBA BABoK:
Need — a problem or opportunity to be addressed.
Requirement — a usable representation of a need.
Business requirements — statements of goals, objectives, and outcomes that describe why a change has been initiated.
Stakeholder requirement — a description of the needs of a particular stakeholder or class of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business requirements and the various categories of solution requirements.
Solution requirements — describes the capabilities and qualities of a solution that meets the stakeholder requirements.
Functional requirements — (a subcategory of solution requirements) describe the capabilities that a solution must have in terms of the behaviour and information that the solution will manage.
User story — a small, concise statement of functionality or quality needed to deliver value to a specific stakeholder.
На мой взгляд Gentoo — это LFS (Linux from Scratch), в котором всю рутину автоматизировали. То есть сравнивать его с бинарными дистрибутивами просто некорректно: Gentoo — это конструктор, он не для того, чтобы по-быстрому установить и запустить браузер. Для конструктора важна максимальная гибкость в конфигурации. И без компиляции из исходников просто не обойтись.
USE флаги — это только часть возможностей. Компиляция из исходников позволяет собрать пакеты под конкретную архитектуру; и я говорю не только и не столько под флаги x86, а например, про ARM, MIPS. Как на счет альтернатив glibc? Патчи: у меня достаточно много user patches — что-то сам сделал, что-то откуда-то скачал; без компиляции патчи не применить никак.
Да, компиляцией под конкретное железо можно повысить производительность. Но не намного; если у вас мощное железо, и у вас десктоп, то вы этого просто не заметите. И на самом деле вопросом производительности нужно заниматься: это не просто выставить CFLAGS и задать USE флаги.
Еще я бы рекомендовал Gentoo в образовательных целях. Если вы не дружите с командной строкой, не знаете как работать с разделами и ядром, вы просто не сможете даже установить Gentoo. У меня есть опыт, когда я учил человека Linux по Gentoo handbook; как оказалось, там достаточно широкий охват тем.
У вас мощное железо? У вас нет специфических архитектур? Вы уже в достаточной степени знаете Линукс или у вас есть более приоритетные задачи в жизни? Вам просто нужен десктоп? Тогда вам нужна не Gentoo. Выберите другой дистрибутив. Под каждую задачу — свой инструмент. Вы же не жалуетесь на экскаватор, дескать, много горючего потребляет, под мостом не проходит, а мне нужно просто добраться из дома на работу.
История. У меня Gentoo установлена на 3 компьютерах: моем домашнем десктопе, ноутбуке для жены, ноутбуке отца. Ноутбуки слабые, регулярно их не обновляю. Но раз лет в 5-7 приходится, ибо браузеры сильно протухают. Однажды решил, что сделаю-ка я одинаковые настройки на всех компьютерах, чтобы упростить установку (можно просто скопировать скомпилированную систему), да и обновления в виде бинарных пакетов перенести. Сделал такой профайл, накатил на ноутбук отца. Сразу поступил отзыв, от на самом деле не привередливого пользователя: работает медленнее.
Переустанавливать времени нет, вот докупил памяти, SSD, чтобы хоть как-то компенсировать.
Эта разница… исчезающе мала. Для того же постгреса есть постгрес про, которые с радостью возьмут деньги за поддержку. Для кубернетеса есть условный флант, который будет поначалу поддерживать кластер, обучит инженеров, а потом… сами знаете, что потом.
Конечно есть. Но вот только мало кто этим пользуется. Большинство рассчитывают, что без этого получится обойтись.
Ну, а чо — давайте тогда вообще не пользоваться открытыми стандартами на языки типа С, С++, Джава....
А это к чему? Мы здесь говорим про нереалистичные ожидания в финансовом аспекте.
Если переходить с postgres на оракл, тоже успех не гарантирован.
Не гарантирован. Но есть разница.
Если вы будете переходить с Postgres на Oracle, то при заключении контракта, Oracle вам будет очень настойчиво предлагать тренинги. И, если вы дадите себя уговорить, то ваш спец Петя уже сходу хоть немного узнает специфику Orcale и сможет сравнить с Postgres. Определенный процент проблем на старте это уберет. В отличии от перехода Oracle->Postgres, когда Петя будет в авральном режиме шерстить StackOverflow после заведения блокера. Очень мало кто при переходе на бесплатные open-source компоненты заказывает специализированные тренинги для своих сотрудников, и это первый фактор риска.
Еще Oracle предложит вам тех. поддержку, так что Петя даже сможет написать кому-то и ожидать получение ответа в оговоренные сроки. Для вашего примера: какой процент компаний подписывает контракт со сторонней компанией на тех. поддержку docker, nginx, postgres, symfony, vuejs, ...? Этого обычно не закладывают в бизнес-кейс, ибо тогда он становится не таким привлекательным.
На самом деле есть четкое определение: проект успешен тогда, когда он выполнен 1) в срок 2) в бюджет 3) достигнуты цели проекта.
Цитата, которую вы привели, относилась к проектам, целью которых являлась снижение операционных затрат, связанных с сопровождением ПО. То есть простыми словами: финансовому директору подавался на стол проект, который говорил: вот сейчас мы за время Х и с бюджетом Y перейдем на open-source технологии, и будем тратить на Z меньше. Так вот в большинстве случаев такие проекты терпят крах. Да, не всегда, конечно, но чаще чем другие. Переформулирую: ожидания по X (сроки), Y (бюджет), Z (цель — снижение затрат) как правило занижены в несколько раз по сравнению с реальностью. Особенно если у компании был не большой опыт работы с open-source. То есть такие проекты имеют очень, очень высокий уровень риска.
Если не брать во внимание новости и слухи, то лично я работал на проектах в продуктовой компании, которая использовала в частности Oracle базы данных. Потом решили перейти на PostgreSQL. А что — почти то же самое, только за лицензию платить не нужно. У нас есть аксакалы Оракла, они быстро освоят PostgreSQL — это было общее видение. Как бы не так. Я не девелопер, но участвовал в общих митингах, и был свидетелям того, с каким скрипом всё продвигалось. В конце-концов мы справились, но явно не в ожидаемое время и бюджет.
На мой взгляд, при словах open-source у многих людей сразу возникают ложные ожидания.
Например, считается что open-source проекты развиваются сообществом. Во-первых, у всех разные определения понятия «сообщество» в плане численности и объема вклада. Во-вторых, какое бы вы ни дали определение сообщества, такие проекты вы в природе найдете; но это будут скорее исключения. Правильней было бы сказать так: open-source — это проекты, в которых сообщество имеет возможность принять развитие; но вовсе не обязано, и не факт, что оно это делает. Собственно, в этой статье это и описано. Для компаний имеет смысл выбирать open-source компоненты для критичных компонент только в том случае, если имеется возможность привлечь людей/партнеров для поддержки; но ни в коем случае нельзя рассчитывать на бесплатную поддержку некоего абстрактного сообщества.
Также, есть расхожее мнение о том, что open-source проекты более безопасны, так как любой желающий может проверить код. Опять же, ключевое слово «может»: не факт, что кто-то это в реальности делает. Но лично вы — да, можете. Я бы сказал так: если вам важна безопасность, и вы можете найти компетентных спецов, которые могут проверить код, и вы намереваетесь это делать, то, да, open-source имеет для вас преимущество.
Open-source часто ассоциируют с финансовой выгодой: никто не требует покупать лицензии, не навязывает тех. поддержку — снижение операционных затрат вроде как налицо. Как по мне, корпоративный проект, основанный на open-source компонентах и на таком вот видении, скорее всего потерпит крах. Не обязательно, но с довольно большой вероятностью.
Правда, с точки зрения рынка open-source имеет неоспоримое преимущество в том, что потенциально много компаний могут осуществлять тех. поддержку. Опять же — «потенциально», «могут», и там еще нюансы.
Еще один неоспоримый плюс в том, вы имеете возможность добавить свои фичи даже если создатели/мейнтейнеры не поддержат ваши изменения. При условии что, вас устраивает лицензия, у вас есть спецы, вы готовы далее поддерживать форк и т. п.
То есть open-source — это скорее о возможностях, но не о дивном новом мире, где всё делается за вас.
Обычно люди, которые имеют возможность и желание делать то, что нравится в спокойном темпе, не выгорают.
Мой комментарий был для тех, кто либо не имеет желания (как я), либо не имеет возможности.
Касательно меня: я готов сейчас променять возможность «делать то, что нравится в спокойном темпе» на более быстрый профессиональный и материальный рост. Ни в коем случае не пытаюсь никому навязывать этот путь.
Привет. Я являюсь хомячком бегущим в… Хм, а как вы определяете, вы находитесь в колесе или на лестнице? На мой взгляд это является вторым по важности вопросом. Именно вторым. А первым…
(здесь интригующая пауза).
Я вообще по жизни являюсь критиком, а потому скажу: спасибо за статью. Поднятая тема очень важна, особенно в современных реалиях. Об этом нужно говорить, делиться опытом, будоражить умы, чтобы искали всё новые инструменты.
Я недавно был почти в таком состоянии, сейчас постепенно выкарабкиваюсь, вот несколько из тех вещей, которые я бы желал, чтобы мне кто-то сказал раньше.
1. Колесо или лестница. Каждый должен сформировать для себя четкий, буквально численный, критерий лестницы. При невыполнении критерия, в вашу жизнь добавляется важный и срочный проект — проект зеро. Мой критерий таков: смена рода деятельности каждые 1.5-2 года. Уточнение критерия: с этим изменением вы начинаете заниматься другими задачами примерно 70% времени и на рынке вы дороже стоите. Пример: изменение позиции, работа с другими технологиями. Если нет — меняем копанию, притом в (само)принудительном порядке. Это и есть важный и срочный проект. И не просто меняем на любую, но с повышением оклада на 20% минимум. Не получается? Значит «долбим» пока не получится, подходим с умом: читать про написание резюме, прохождение собеседований, изучать что просят работодатели и нарабатывать эти активы (сертификации, базворды в резюме и т. п.), начинать общаться с людьми на предмет кто может помочь (знакомые), холодный контакт через соц. сети — какие спецы сейчас требуются в вашу компанию, какой опыт/знания буду спрашивать, что нужно чтобы меня к вам взяли и т. п.
2. Какой ваш ритм? Это первый по важности вопрос. Работать день и ночь плохо? Я знаю компанию, которая на этапе собеседования говорит, что «у нас вы будете работать 80 часов в неделю» (для тех кто сонный: в рабочей неделе обычно 40 рабочих часов; иными словами они предлагают работать в рабочие дни, скажем с 7:00 утра до 2:00-3:00 ночи). И они выполняют своё обещание. И это компания мечты для многих. Работать 8 часов в день… Давайте будем честными: это не для всех. Для многих это самообман. Это как каждые 1-2 часа отходить от компьютера и делать зарядку для глаз — минздрав рекомендует, но как много людей это на практике делает? Нет, кто-то, конечно, делает… возможно. Но те, кто не делает — перестаньте себя за это корить, и не пытайтесь найти в этом корень всех своих проблем. И перестаньте повторять эту мантру. Мне комфортно работать 10-12 часов в день. Пытался работать до 2-3 ночи — в студенчестве мог, но сейчас наблюдаю упадок производительности. Пытался работать 8 часов в день — ну мне стыдно выдавать такие результаты, я ведь могу больше, да и рост прекращается. 8 часов? Да, рекомендую всем, кто спрашивает. Бесспорно. Но это не для меня. Давайте быть честными с собой. А какое ваше время работы, при котором у вас не наблюдается деградация?
3. Отдых нужен. Рекомендую: отпуск 2-3 раза в год, притом один отпуск на 2 недели. Не получается? Работа не отпускает? Подаем заявление на отпуск за 3 месяца. За полгода. Хорошо: за год. Ведь к тому времени мы ж планируем разгрестись, так? «Я не могу подтвердить заявку, мы так далеко не планируем, может в то время у нас будет аврал» — бежим из такой компании: если менеджмент не умеет менеджить работу, когда ему за полгода рассказали о доступности ресурсов — это плохой менеджмент, счастья в такой комании не будет. И жесткое правило: нет, я не могу отменить отпуск. «Мне очень жаль, да, я понимаю, что важно, да горим. Но… заплачено за отель, предоплату не возвращают, билеты на самолет куплены, и вообще я лечу с семьёй, если не полечу я, то и они. Да, там может не быть связи, я постараюсь, но, правда, готовьтесь к тому, что нет, вайфай в отеле сами знаете какой. Давайте сейчас продумаем всё, что может понадобиться, готов(а) до отпуска работать до 2:00 ночи, но отпуск отменить не могу. Да, я понимаю, что возможно вы найдете другого человека… Я очень хочу, вы меня знаете, но обстоятельства выше меня.» В отпуске принципиально отвечаем на письма, скайпы, вайберы — не чаще чем раз в неделю. Лучше даже не проверять, но, опять же, давайте будем честными с собой: совсем не проверять не сможем. Но не отвечать — в человеческих силах. И открою секрет: армагеддона не случится. Я как-то был в жестком проекте, каждый день, как атлант, вытягивал всё на себе. Кто как не я. А потом неожиданно попал на операционный стол. Всё обошлось, но неожиданно на две недели выпал из работы. И знаете что — проект не рухнул. Завтра обещал клиенту дать судьбоносный ответ, потом на следующий день пропал, казалось, что всё!!! Ан-нет. Всё как-то образовалось. Я сам не знаю как. Магия, правда. Но с тех пор я понял: она, магия, есть, даже если я не знаю как это происходит. Да, и про связь: очень рекомендую горы, сплавы на катамаранах, лыжи зимой и т. п. Во-первых один день отдыха вам пойдет как за неделю (да, именно такой обменный курс), потом спорт, свежий воздух, общение с людьми (если едете не одни), но самое главное — там связь плохая, если вообще есть. Вот правда, попробуйте, не пожалеете.
4. «Важно = срочно» или «Хочешь что-то сделать, делай сразу». Пусть вы не занимаетесь тайм менеджментом (а когда им заниматься: работать нужно), пусть с головой в делах, но это правило должно быть железным. Как это выглядит на практике? Проснулись утром, ноутбук в постель, проверять почту… Нет, стоп, я уже 2 года занимаюсь тем же (см. п. 1). Лестница превратилась в колесо. Перед почтой ровно 1 час, закрываем мессенджеры, ставим телефон на тихую, закрываем почту и рассылаем резюме. Для всех — я еще сплю, я еще в пробке, потом буду извиняться, но сейчас у меня проект зеро: не дать лестнице превратиться в колесо.
Есть массив значений V(alues). Есть массив Q(uery), который содержит индексы массива V. Нужно получить массив R(esult) по следующему правилу: из массива Q выбираем индекс, по нему выбираем значение из V. То есть: R[i] = V[ Q[i] ]
А в идеале такая цепочка преобразований может быть достаточно длинной, например: R[i] = V[ A1[ A2[ Q[i] ] ] ]
… в тех сценариях, для которых она (программа) предназначена. И только в них. Если вы пишите тулу, которая запустится пару десятков раз, да еще и из ваших рук, прорабатывать все exceptional scenarions не имеет никакого смысла. Особенно если это негативно сказывается на скорости выполнения.
На этот раз хотелось бы увидеть код от вас. Сравнение реализации на Python и C++, замеры скорости.
Правило хорошего дизайна программы — делать ровно то, что необходимо для выполнения задачи.
Неужели? Тогда объясните, пожалуйста, почему на банальном цикле и сложении, код на C++ оказывается в 100 раз быстрее кода на Python. И на этот раз попрошу пруфы от вас, если у вас есть контр-аргументы:
Тест:
$ ./test.py
100000000
Execution time: 45297.41560799994 milliseconds
$ g++ ./test.cpp && ./a.out
100000000
Execution time: 405 milliseconds
test.py
test.cpp:
Ну, например, проверка выхода индекса за границы массива.
Вот этот Python код завершится исключением, так как проверяет границы:
Этот код на C++ код завершается нормально, так не делает такой проверки.
Да, с одной стороны это возможность выстрелить себе в ногу. А с другой стороны, если у меня в программе невозможно выйти за пределы массива by design, зачем это каждый раз это проверять? В большинстве случаев это не мешает, но когда обрабатываются большие объемы данных, и важна производительность, это может сыграть роль. И это только один из примеров.
Кстати, в C++ тоже можно писать так, чтобы библиотека автоматически делала проверку. Следующий код на C++ завершится исключением:
То есть в C++ можно писать и так, и так. Но нужно время, обучить человека это понимать. И поэтому всё упирается в длительность подготовки специалиста.
В С++ исключения есть.
Если С++ использовать по уму, то выстрелов в ногу тоже не будет.
Суть в том, что программист высокого уровня (обученный и с опытом) может написать как быструю программу на Python, так и безопасную программу на C++. А значит, выбор языка будет определяться другими факторами: конкретным сценарием / use case'ом, практиками принятыми в организации и т. п. Преимуществом языков с автоматизацией управления памятью, дополнительными проверками, прозрачной конвертацией типов и т. п. состоит в том, что человек с нуля может уже через небольшое время начать писать программы, которые будут работать. Если же есть возможность нанять человека уже со значительным опытом, то это преимущество нивелируется.
Да, именно поэтому. Они делают 1000 проверок там, где достаточно 10. Соответственно, приходится выбирать: либо написать программу быстро, либо написать быструю программу.
Что ты понимаешь под «нормальными исключениями», и где по твоему мнению их нет?
Почему?
Gentoo — source-based дистрибутив. И подходит он для соотв. задач — см. ниже.
А альтернатив не так уж и много.
В отличии от LFS у Gentoo пакетный менеджер, системные утилиты, конфигурации и всё то, что позволяет использовать Gentoo как полноценный основной дистрибутив, даже для десктопа. LFS такого не позволяет.
Calculate — по сути бинарный вариант Gentoo; при том, как только мы хотим использовать фичи source-based дистрибутива, он превращается в Gentoo.
Не могу сказать, что хорошо знаю остальные source-based дистрибутивы, но знаю, что у Gentoo отличная документация (по опросам лучше только у Arch Linux), великолепный пакетный менеджер (единственный минус — медленный), много софта в репозитории. Ну, и Gentoo постоянно развивается.
Теперь что касается задач.
Сначала скажу в каких случаях Gentoo не подходит или не является оптимальным выбором:
— Для задач, которые не выставляют специальных требований к дистрибутиву.
— Для задач, для которых уже есть соотв. дистрибутив, и он вас устраивает.
— Пользователям, которые недостаточно хорошо знают Линукс, и не стремятся эти знания получить: такие пользователи просто не смогут установить Gentoo, а если таки установят, потом намучаются с ней.
Иными словами, если вас всё устраивает в Ubuntu, SuSe, Red Hat, и т. п., или если вы новичок, то Gentoo вам не нужна.
Когда Gentoo подходит.
1. Работа с исходным кодом на уровне дистрибутива. Представим, компанию, бизнес которой опирается на безопасность. Это может быть государственная организация, крупная финансовая структура и т. п. Притом требования безопасности настолько высоки, что в некоторых случаях требуются свежайшие версии софта (live в терминологии Gentoo), возможно — аудит кода (и компания имеет соотв. специалистов), в течении часов — применения патчей для закрытия 0-day уязвимостей, а может и создание этих патчей и т. п. Gentoo здесь будет хорошим выбором, так как source-based: из репозитория загружаются исходники, компиляция осуществляется локально (естественно, для компании — на соотв. серверах); при этом есть спец. средства для работы с патчами. Реальные примеры: Gentoo на Нью-Йоркской фондовой бирже и в Национальном агентстве кибербезопасности Франции (ANSSI).
2. Специфичная архитектура. Gentoo только поддерживает ARM, MIPS, HPPA, PowerPC, Sparc и др. Если жизнь вас столкнула с такой архитектурой, и под нее нет соотв. дистрибутива, или дистрибутив чем-то вас не устраивает (например, свежестью софта в репозиториях), то Gentoo может оказаться хорошим выбором.
3. Оптимизация под конкретное железо. Представим крупного cloud service provider или другую компанию, у которой одной из основных статей расходов является IT инфраструктура. Улучшение эффективности даже на несколько процентов может вылиться в миллионы долларов экономии. А максимальной оптимизации можно добиться только компилируя софт под конкретную платформу.
4. Оптимизация с целью минимального потребления ресурсов. Очень актуально в связи с популяризацией IoT и контейнеризации. Например, CoreOS (правда ее уже купил Red Hat).
5. Создание нового дистрибутива. На самом деле это покрывает сценарии описанные выше, но может включать и вообще любого рода конфигурации и кастомизации. В Gentoo есть механизмы профилей (что позволяет комбинировать общие настройки со специфичными для данного хоста); это в дополнение к средствам управления репозиториями, утилитам создания бинарных пакетов и т. п. Да, это умеют и другие дистрибутивы; но, в Gentoo можно выбрать нужные версии ПО (ибо rolling-release), скомпилировать под конкретную платформу, наложить свои патчи, избавиться от лишних зависимостей (ибо source-based). И то, что получилось, распространять как дистрибутив. Не только как публичный, но и как закрытый для внутреннего пользования для какой-то корпорации. Реальные примеры: Chrome OS, тот самый что Google устанавливает на Chromebook. Ну и другие; но понятно, что информация приватных дистрибутивах компаний не особо публикуется.
И от кровавого энтерпрайса перейдем к домашнему использованию Gentoo.
6. Обучение Линукс. По сценариям вверху можно понять на какого уровня специалистов рассчитан Gentoo. А поэтому там нет графических инсталляторов и красивых окошечек для домохозяек — только командная строка и текстовые конфиги. Установить Gentoo, настроить ее до комфортного состояния, а потом еще и пользоваться ей новичок не сможет. А если захочет, то придется разобраться в основных принципах и инструментах Linux: командная строка, работа с разделами жесткого диска, сборка ядра, и т. п. Я лично имею опыт обучения Linux человека по Gentoo handbook: и опыт успешный, потому как после теории человек сразу на практике видит, как это используется и зачем это нужно. Да и я сам, признаться, когда первый раз устанавливал Gentoo, много нового узнал. Дистрибутив с wizard-based инсталлятором и графическими конфигурационными утилитами такого ее даст. Кроме того, Gentoo ставит перед тобой вопросы, на которые нужно дать осмысленный ответ: systemd vs openrc, alsa vs pulseaudio, dhcpcd vs dhclient, syslog vs rsyslog vs syslog-ng и т. п.
7. Порядок в системе. Это очень субъективный сценарий, но есть люди, которые очень любят порядок в системе: ничего лишнего не установлено, автоматически ничего не запускается такого, чего явно не просили, система что-то меняет только с разрешения пользователя. И при этом всё максимально автоматизировано, всё делается в пару нажатий клавиш. Я знаю потому, что я сам к таким отношусь. Да, такое можно сделать на других дистрибутивах; просто в других дистрибутивах ты будешь вырезать то, что не нужно, а в Gentoo ты устанавливаешь только то, что нужно, что как по мне, проще и логичней. Мне нравится, что Gentoo дает выбор альтернатив софта (примеры выше). Мне очень нравится, как Gentoo работает с конфигами: если конфиг должен поменяться (а при обновлении софта такое может потребоваться), то пакетный менеджер кладет его рядом и просит пользователя посмотреть и принять изменения и перенести свои настройки; а я еще настроил авто-патчинг конфигов, так что теперь у меня конфиги обновляются автоматически и при этом не перетирают мои настройки. USE флаги отсекают лишние зависимости. Set'ы позволяют мне сделать сетап, который я тиражирую на несколько компьютеров, при этом легко добавляя индивидуальность где это нужно. Ну, и обновления запускаются в пару нажатий клавиш и, опять же, идут так, как мне нужно. Я в свое время перепробовал Red Hat, Slackware, Suse, но Gentoo мне показался наиболее простым, понятным, а еще система не думает, что она умнее меня и лучше знает, что мне нужно.
Наверное, некоторые пункты достойны холивора. Но всё-таки, надеюсь, я дал ответ на вопрос.
Автора статьи, возможно, смутило то, что пользовательские истории как правило не достаточно конкретные, чтобы можно было начинать разработку.
Есть несколько видов требований: бизнес требования (business requirements), требования заинтересованных сторон (stakeholder requirements), требования к решению (solution requirements). Функциональные требования (functional requirement) — это подкатегория требований к решению.
В процессе бизнес анализа, нужно понимать потребности бизнеса, потребности конкретных пользователей, и т. п., чтобы убедиться, что тот функционал, то решение, которое мы разрабатываем, это то, что нужно заказчику. Пользовательские истории выполняют эту функцию. В большинстве это не то, что сразу можно брать в разработку, это скорее промежуточный этап.
В контракте же нужно фиксировать требования, с одной стороны, не очень детально, чтобы у разработчиков была возможность для маневров, а с другой стороны — достаточно детально, чтобы нельзя было позже раздуть объем работ. Это на грани искусства, но любой опытный бизнес-аналитик должен быть способен это сделать. Некоторые пользовательские истории удовлетворяют этим требования, и могут быть использованы в контракте.
Из IIBA BABoK:
Need — a problem or opportunity to be addressed.
Requirement — a usable representation of a need.
Business requirements — statements of goals, objectives, and outcomes that describe why a change has been initiated.
Stakeholder requirement — a description of the needs of a particular stakeholder or class of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business requirements and the various categories of solution requirements.
Solution requirements — describes the capabilities and qualities of a solution that meets the stakeholder requirements.
Functional requirements — (a subcategory of solution requirements) describe the capabilities that a solution must have in terms of the behaviour and information that the solution will manage.
User story — a small, concise statement of functionality or quality needed to deliver value to a specific stakeholder.
На мой взгляд Gentoo — это LFS (Linux from Scratch), в котором всю рутину автоматизировали. То есть сравнивать его с бинарными дистрибутивами просто некорректно: Gentoo — это конструктор, он не для того, чтобы по-быстрому установить и запустить браузер. Для конструктора важна максимальная гибкость в конфигурации. И без компиляции из исходников просто не обойтись.
USE флаги — это только часть возможностей. Компиляция из исходников позволяет собрать пакеты под конкретную архитектуру; и я говорю не только и не столько под флаги x86, а например, про ARM, MIPS. Как на счет альтернатив glibc? Патчи: у меня достаточно много user patches — что-то сам сделал, что-то откуда-то скачал; без компиляции патчи не применить никак.
Да, компиляцией под конкретное железо можно повысить производительность. Но не намного; если у вас мощное железо, и у вас десктоп, то вы этого просто не заметите. И на самом деле вопросом производительности нужно заниматься: это не просто выставить CFLAGS и задать USE флаги.
Еще я бы рекомендовал Gentoo в образовательных целях. Если вы не дружите с командной строкой, не знаете как работать с разделами и ядром, вы просто не сможете даже установить Gentoo. У меня есть опыт, когда я учил человека Linux по Gentoo handbook; как оказалось, там достаточно широкий охват тем.
У вас мощное железо? У вас нет специфических архитектур? Вы уже в достаточной степени знаете Линукс или у вас есть более приоритетные задачи в жизни? Вам просто нужен десктоп? Тогда вам нужна не Gentoo. Выберите другой дистрибутив. Под каждую задачу — свой инструмент. Вы же не жалуетесь на экскаватор, дескать, много горючего потребляет, под мостом не проходит, а мне нужно просто добраться из дома на работу.
Так есть уже. Называется Calculate Linux.
История. У меня Gentoo установлена на 3 компьютерах: моем домашнем десктопе, ноутбуке для жены, ноутбуке отца. Ноутбуки слабые, регулярно их не обновляю. Но раз лет в 5-7 приходится, ибо браузеры сильно протухают. Однажды решил, что сделаю-ка я одинаковые настройки на всех компьютерах, чтобы упростить установку (можно просто скопировать скомпилированную систему), да и обновления в виде бинарных пакетов перенести. Сделал такой профайл, накатил на ноутбук отца. Сразу поступил отзыв, от на самом деле не привередливого пользователя: работает медленнее.
Переустанавливать времени нет, вот докупил памяти, SSD, чтобы хоть как-то компенсировать.
Конечно есть. Но вот только мало кто этим пользуется. Большинство рассчитывают, что без этого получится обойтись.
А это к чему? Мы здесь говорим про нереалистичные ожидания в финансовом аспекте.
Не гарантирован. Но есть разница.
Если вы будете переходить с Postgres на Oracle, то при заключении контракта, Oracle вам будет очень настойчиво предлагать тренинги. И, если вы дадите себя уговорить, то ваш спец Петя уже сходу хоть немного узнает специфику Orcale и сможет сравнить с Postgres. Определенный процент проблем на старте это уберет. В отличии от перехода Oracle->Postgres, когда Петя будет в авральном режиме шерстить StackOverflow после заведения блокера. Очень мало кто при переходе на бесплатные open-source компоненты заказывает специализированные тренинги для своих сотрудников, и это первый фактор риска.
Еще Oracle предложит вам тех. поддержку, так что Петя даже сможет написать кому-то и ожидать получение ответа в оговоренные сроки. Для вашего примера: какой процент компаний подписывает контракт со сторонней компанией на тех. поддержку docker, nginx, postgres, symfony, vuejs, ...? Этого обычно не закладывают в бизнес-кейс, ибо тогда он становится не таким привлекательным.
На самом деле есть четкое определение: проект успешен тогда, когда он выполнен 1) в срок 2) в бюджет 3) достигнуты цели проекта.
Цитата, которую вы привели, относилась к проектам, целью которых являлась снижение операционных затрат, связанных с сопровождением ПО. То есть простыми словами: финансовому директору подавался на стол проект, который говорил: вот сейчас мы за время Х и с бюджетом Y перейдем на open-source технологии, и будем тратить на Z меньше. Так вот в большинстве случаев такие проекты терпят крах. Да, не всегда, конечно, но чаще чем другие. Переформулирую: ожидания по X (сроки), Y (бюджет), Z (цель — снижение затрат) как правило занижены в несколько раз по сравнению с реальностью. Особенно если у компании был не большой опыт работы с open-source. То есть такие проекты имеют очень, очень высокий уровень риска.
Если не брать во внимание новости и слухи, то лично я работал на проектах в продуктовой компании, которая использовала в частности Oracle базы данных. Потом решили перейти на PostgreSQL. А что — почти то же самое, только за лицензию платить не нужно. У нас есть аксакалы Оракла, они быстро освоят PostgreSQL — это было общее видение. Как бы не так. Я не девелопер, но участвовал в общих митингах, и был свидетелям того, с каким скрипом всё продвигалось. В конце-концов мы справились, но явно не в ожидаемое время и бюджет.
Например, считается что open-source проекты развиваются сообществом. Во-первых, у всех разные определения понятия «сообщество» в плане численности и объема вклада. Во-вторых, какое бы вы ни дали определение сообщества, такие проекты вы в природе найдете; но это будут скорее исключения. Правильней было бы сказать так: open-source — это проекты, в которых сообщество имеет возможность принять развитие; но вовсе не обязано, и не факт, что оно это делает. Собственно, в этой статье это и описано. Для компаний имеет смысл выбирать open-source компоненты для критичных компонент только в том случае, если имеется возможность привлечь людей/партнеров для поддержки; но ни в коем случае нельзя рассчитывать на бесплатную поддержку некоего абстрактного сообщества.
Также, есть расхожее мнение о том, что open-source проекты более безопасны, так как любой желающий может проверить код. Опять же, ключевое слово «может»: не факт, что кто-то это в реальности делает. Но лично вы — да, можете. Я бы сказал так: если вам важна безопасность, и вы можете найти компетентных спецов, которые могут проверить код, и вы намереваетесь это делать, то, да, open-source имеет для вас преимущество.
Open-source часто ассоциируют с финансовой выгодой: никто не требует покупать лицензии, не навязывает тех. поддержку — снижение операционных затрат вроде как налицо. Как по мне, корпоративный проект, основанный на open-source компонентах и на таком вот видении, скорее всего потерпит крах. Не обязательно, но с довольно большой вероятностью.
Правда, с точки зрения рынка open-source имеет неоспоримое преимущество в том, что потенциально много компаний могут осуществлять тех. поддержку. Опять же — «потенциально», «могут», и там еще нюансы.
Еще один неоспоримый плюс в том, вы имеете возможность добавить свои фичи даже если создатели/мейнтейнеры не поддержат ваши изменения. При условии что, вас устраивает лицензия, у вас есть спецы, вы готовы далее поддерживать форк и т. п.
То есть open-source — это скорее о возможностях, но не о дивном новом мире, где всё делается за вас.
Мой комментарий был для тех, кто либо не имеет желания (как я), либо не имеет возможности.
Касательно меня: я готов сейчас променять возможность «делать то, что нравится в спокойном темпе» на более быстрый профессиональный и материальный рост. Ни в коем случае не пытаюсь никому навязывать этот путь.
(здесь интригующая пауза).
Я вообще по жизни являюсь критиком, а потому скажу: спасибо за статью. Поднятая тема очень важна, особенно в современных реалиях. Об этом нужно говорить, делиться опытом, будоражить умы, чтобы искали всё новые инструменты.
Я недавно был почти в таком состоянии, сейчас постепенно выкарабкиваюсь, вот несколько из тех вещей, которые я бы желал, чтобы мне кто-то сказал раньше.
1. Колесо или лестница. Каждый должен сформировать для себя четкий, буквально численный, критерий лестницы. При невыполнении критерия, в вашу жизнь добавляется важный и срочный проект — проект зеро. Мой критерий таков: смена рода деятельности каждые 1.5-2 года. Уточнение критерия: с этим изменением вы начинаете заниматься другими задачами примерно 70% времени и на рынке вы дороже стоите. Пример: изменение позиции, работа с другими технологиями. Если нет — меняем копанию, притом в (само)принудительном порядке. Это и есть важный и срочный проект. И не просто меняем на любую, но с повышением оклада на 20% минимум. Не получается? Значит «долбим» пока не получится, подходим с умом: читать про написание резюме, прохождение собеседований, изучать что просят работодатели и нарабатывать эти активы (сертификации, базворды в резюме и т. п.), начинать общаться с людьми на предмет кто может помочь (знакомые), холодный контакт через соц. сети — какие спецы сейчас требуются в вашу компанию, какой опыт/знания буду спрашивать, что нужно чтобы меня к вам взяли и т. п.
2. Какой ваш ритм? Это первый по важности вопрос. Работать день и ночь плохо? Я знаю компанию, которая на этапе собеседования говорит, что «у нас вы будете работать 80 часов в неделю» (для тех кто сонный: в рабочей неделе обычно 40 рабочих часов; иными словами они предлагают работать в рабочие дни, скажем с 7:00 утра до 2:00-3:00 ночи). И они выполняют своё обещание. И это компания мечты для многих. Работать 8 часов в день… Давайте будем честными: это не для всех. Для многих это самообман. Это как каждые 1-2 часа отходить от компьютера и делать зарядку для глаз — минздрав рекомендует, но как много людей это на практике делает? Нет, кто-то, конечно, делает… возможно. Но те, кто не делает — перестаньте себя за это корить, и не пытайтесь найти в этом корень всех своих проблем. И перестаньте повторять эту мантру. Мне комфортно работать 10-12 часов в день. Пытался работать до 2-3 ночи — в студенчестве мог, но сейчас наблюдаю упадок производительности. Пытался работать 8 часов в день — ну мне стыдно выдавать такие результаты, я ведь могу больше, да и рост прекращается. 8 часов? Да, рекомендую всем, кто спрашивает. Бесспорно. Но это не для меня. Давайте быть честными с собой. А какое ваше время работы, при котором у вас не наблюдается деградация?
3. Отдых нужен. Рекомендую: отпуск 2-3 раза в год, притом один отпуск на 2 недели. Не получается? Работа не отпускает? Подаем заявление на отпуск за 3 месяца. За полгода. Хорошо: за год. Ведь к тому времени мы ж планируем разгрестись, так? «Я не могу подтвердить заявку, мы так далеко не планируем, может в то время у нас будет аврал» — бежим из такой компании: если менеджмент не умеет менеджить работу, когда ему за полгода рассказали о доступности ресурсов — это плохой менеджмент, счастья в такой комании не будет. И жесткое правило: нет, я не могу отменить отпуск. «Мне очень жаль, да, я понимаю, что важно, да горим. Но… заплачено за отель, предоплату не возвращают, билеты на самолет куплены, и вообще я лечу с семьёй, если не полечу я, то и они. Да, там может не быть связи, я постараюсь, но, правда, готовьтесь к тому, что нет, вайфай в отеле сами знаете какой. Давайте сейчас продумаем всё, что может понадобиться, готов(а) до отпуска работать до 2:00 ночи, но отпуск отменить не могу. Да, я понимаю, что возможно вы найдете другого человека… Я очень хочу, вы меня знаете, но обстоятельства выше меня.» В отпуске принципиально отвечаем на письма, скайпы, вайберы — не чаще чем раз в неделю. Лучше даже не проверять, но, опять же, давайте будем честными с собой: совсем не проверять не сможем. Но не отвечать — в человеческих силах. И открою секрет: армагеддона не случится. Я как-то был в жестком проекте, каждый день, как атлант, вытягивал всё на себе. Кто как не я. А потом неожиданно попал на операционный стол. Всё обошлось, но неожиданно на две недели выпал из работы. И знаете что — проект не рухнул. Завтра обещал клиенту дать судьбоносный ответ, потом на следующий день пропал, казалось, что всё!!! Ан-нет. Всё как-то образовалось. Я сам не знаю как. Магия, правда. Но с тех пор я понял: она, магия, есть, даже если я не знаю как это происходит. Да, и про связь: очень рекомендую горы, сплавы на катамаранах, лыжи зимой и т. п. Во-первых один день отдыха вам пойдет как за неделю (да, именно такой обменный курс), потом спорт, свежий воздух, общение с людьми (если едете не одни), но самое главное — там связь плохая, если вообще есть. Вот правда, попробуйте, не пожалеете.
4. «Важно = срочно» или «Хочешь что-то сделать, делай сразу». Пусть вы не занимаетесь тайм менеджментом (а когда им заниматься: работать нужно), пусть с головой в делах, но это правило должно быть железным. Как это выглядит на практике? Проснулись утром, ноутбук в постель, проверять почту… Нет, стоп, я уже 2 года занимаюсь тем же (см. п. 1). Лестница превратилась в колесо. Перед почтой ровно 1 час, закрываем мессенджеры, ставим телефон на тихую, закрываем почту и рассылаем резюме. Для всех — я еще сплю, я еще в пробке, потом буду извиняться, но сейчас у меня проект зеро: не дать лестнице превратиться в колесо.
Добра.
Допустим так:
Выражение для https://matrixcalc.org: {{10,20,30}} * {{0,0,1},{1,0,0},{0,1,0}}
Тогда нужен быстрый способ преобразовать 2 в (0 1 0).
Есть массив значений V(alues). Есть массив Q(uery), который содержит индексы массива V. Нужно получить массив R(esult) по следующему правилу: из массива Q выбираем индекс, по нему выбираем значение из V. То есть:
R[i] = V[ Q[i] ]А в идеале такая цепочка преобразований может быть достаточно длинной, например:
R[i] = V[ A1[ A2[ Q[i] ] ] ]Есть ли SIMD инструкции, для подобной задачи?
А чем мотивирован выбор Azure вместо AWS или Google Cloud?