Если вы про Яндекс, то вся эта радость, на сколько я знаю, для Java не подходит. И чтобы только сгенерировать проект для Idea приходится минутами ждать (локальную) компиляцию протобуфов вместе с protoc и другим туллингом. Да и с C++ вы, как мне кажется, приукрашиваете и не говорите о проблемах. Например, распространённая среди коллег плюсовиков практика рефакторинга седом для меня является признаком наличия таких проблем.
Недостатки вроде очевидны: вендор-лок, сложно искать и удерживать специалистов и подозреваю, что есть и другие сложности.
А что хорошего взамен? Должны быть какие-то существенные преимущества перед более распространёнными технологиями, чтобы использование этой технологии было обосновано, т.к. сложность поиска специалистов обычно чуть ли не основной аргумент за или против применения той или иной технологии. Однако ни в статье, ни в вашем ответе я таких существенных причин не нашёл. Хотя возможно пропустил по невнимательности.
Можно для воспроизводимости использовать ed (sed -i, как я сегодня узнал, пишет во временный файл, а потом заменяет им старый, поэтому не подходит).
Примерно так: printf '3s/02/2/\nw\n' | ed -s test.sh.
Мой сниппет для воспроизведения:
$ ed -V
GNU Ed 1.10
...
$ bash --version
GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)
...
$ cat ./test.sh
#!/bin/bash
echo start
sleep 02
# ls -lh # вместо опасной команды
echo finish
sed -i '3s/ 2$/ 02/' test.sh # чтобы он сам себя восстанавливал обратно
Так вот, этот принцип говорит что метрика I компонента должна быть больше метрик I компонентов, которые от него зависят. То есть метрики I должны уменьшаться в направлении зависимости.
Наверное "метрика I компонента должна быть меньше ..."?
Т.е. вы разрабатываете проекты на заказ в общем монорепозитории вашей компании, где хранятся и все разрабатываемые сейчас, и уже готовые заказы? А исходники этих проектов вы заказчикам отдаёте? Как?
Но вы же, надеюсь, не будете спорить, что постоянно переключаться между раскладками и помнить (или постоянно проверять) текущую раскладку — это не удобно и сбивает? Именно об этом и "написано в книжке".
Другое дело, что для ввода на разных языках не так много вариантов, как это можно организовать, и загромождать стол несколькими клавиатурами кажется неудобным. А педали не слишком распространены (и тоже не факт, что это удобно). Т.е. тут модальность выбрана, как меньшее зло. Но злом она от этого быть не перестаёт.
Про vim тут, кстати, уже писали, что модальность была выбрана для борьбы с (более серьёзными) проблемами медленной реакции терминалов, с которыми его тогда использовали. И тогда это было оправдано. Сейчас же эти проблемы далеко не так актуальны, и есть примеры интерфейсов, позволяющих точно так же не отрывать руки от клавиатуры, имея при этом гораздо менее модальный интерфейс (привет от емаксеров). Так что, чтобы утверждать, что "режимы нужны и полезны всем", вместо "ну мне так нравится", нужны какие-то доводы.
Конечно имеет. Т.к. TUI — это, по сути, GUI нарисованный в терминале псевдографикой, то все ваши комментарии в этой ветке теряют всякий смысл. И тематика упомянутой мной книги в одинаковой мере относится как к GUI, так и к TUI.
Спасибо. Я, конечно, имел в виду генератор псевдослучайных чисел, входящий в стандартную библиотеку языка Си, который использовал meduzik в своём примере (на который я сослался выше).
// Прошу прощения, что комментирую эту статью, а не предыдущую, но туда мне писать уже нельзя.
1. Вы можете объяснить, почему в ваших собственных результатах тестирования в предыдущей статье (как и у большинства отписавшихся), большинство функций отработали заметно быстрее при «хаотичной подаче»?
2. Как я понимаю, ваш способ получения «хаотической» последовательности чисел всё ещё оставляет огромное пространство для различных оптимизаций при компиляции и исполнении. Почему вы не используете случайные числа (как предложил meduzik: habrahabr.ru/post/281629/#comment_8854253)?
3. Есть какой-то факт, гарантирующий, что первые 2^32 элементов последовательность вроде «a[i+1] = (19993 * a[i] + 1) % 2^32» переберут все натуральные числа от 0 до 2^32 — 1 по одному разу?
Можно ссылку на источник цитаты? Это же цитата?
Это общая сетка грейдов на всю компанию. Ниже там стажёры, а дальше не разработчики.
Если вы про Яндекс, то вся эта радость, на сколько я знаю, для Java не подходит. И чтобы только сгенерировать проект для Idea приходится минутами ждать (локальную) компиляцию протобуфов вместе с protoc и другим туллингом. Да и с C++ вы, как мне кажется, приукрашиваете и не говорите о проблемах. Например, распространённая среди коллег плюсовиков практика рефакторинга седом для меня является признаком наличия таких проблем.
Недостатки вроде очевидны: вендор-лок, сложно искать и удерживать специалистов и подозреваю, что есть и другие сложности.
А что хорошего взамен? Должны быть какие-то существенные преимущества перед более распространёнными технологиями, чтобы использование этой технологии было обосновано, т.к. сложность поиска специалистов обычно чуть ли не основной аргумент за или против применения той или иной технологии. Однако ни в статье, ни в вашем ответе я таких существенных причин не нашёл. Хотя возможно пропустил по невнимательности.
Можно для воспроизводимости использовать ed (
sed -i, как я сегодня узнал, пишет во временный файл, а потом заменяет им старый, поэтому не подходит).Примерно так:
printf '3s/02/2/\nw\n' | ed -s test.sh.Наверное "метрика I компонента должна быть меньше ..."?
А не посоветуешь, что почитать про то, как такое верифицировать? В Software Foundations, например, так далеко не заходят.
Т.е. вы разрабатываете проекты на заказ в общем монорепозитории вашей компании, где хранятся и все разрабатываемые сейчас, и уже готовые заказы? А исходники этих проектов вы заказчикам отдаёте? Как?
Этот комикс был просто обязан появиться в этом обсуждении: https://xkcd.com/378/
Но вы же, надеюсь, не будете спорить, что постоянно переключаться между раскладками и помнить (или постоянно проверять) текущую раскладку — это не удобно и сбивает? Именно об этом и "написано в книжке".
Другое дело, что для ввода на разных языках не так много вариантов, как это можно организовать, и загромождать стол несколькими клавиатурами кажется неудобным. А педали не слишком распространены (и тоже не факт, что это удобно). Т.е. тут модальность выбрана, как меньшее зло. Но злом она от этого быть не перестаёт.
Про vim тут, кстати, уже писали, что модальность была выбрана для борьбы с (более серьёзными) проблемами медленной реакции терминалов, с которыми его тогда использовали. И тогда это было оправдано. Сейчас же эти проблемы далеко не так актуальны, и есть примеры интерфейсов, позволяющих точно так же не отрывать руки от клавиатуры, имея при этом гораздо менее модальный интерфейс (привет от емаксеров). Так что, чтобы утверждать, что "режимы нужны и полезны всем", вместо "ну мне так нравится", нужны какие-то доводы.
Конечно имеет. Т.к. TUI — это, по сути, GUI нарисованный в терминале псевдографикой, то все ваши комментарии в этой ветке теряют всякий смысл. И тематика упомянутой мной книги в одинаковой мере относится как к GUI, так и к TUI.
Вы путаете. Vim — это TUI или GUI (есть же ещё gvim).
Я бы ещё сослался на книгу Джефа Раскина — Интерфейс: новые направления в проектировании компьютерных систем. Он там, в том числе, достаточно убедительно обосновывает вред модальности для удобства интерфейса.
1. Вы можете объяснить, почему в ваших собственных результатах тестирования в предыдущей статье (как и у большинства отписавшихся), большинство функций отработали заметно быстрее при «хаотичной подаче»?
2. Как я понимаю, ваш способ получения «хаотической» последовательности чисел всё ещё оставляет огромное пространство для различных оптимизаций при компиляции и исполнении. Почему вы не используете случайные числа (как предложил meduzik: habrahabr.ru/post/281629/#comment_8854253)?
3. Есть какой-то факт, гарантирующий, что первые 2^32 элементов последовательность вроде «a[i+1] = (19993 * a[i] + 1) % 2^32» переберут все натуральные числа от 0 до 2^32 — 1 по одному разу?