В каждом топике про фейл большой компании одни и те же комментарии: попытка представить большую компанию как одного недостойного человека. Не надоело?
Хозяева и их агенты бывали разные; некоторые говорили мягко, потому что им было тяжело делать то, что они делали; другие сердились, потому что им было тяжело проявлять жестокость; третьи держались холодно, потому что они давно уже поняли: хозяин должен держаться холодно, иначе ты не настоящий хозяин. И все они подчинялись силе, превосходящей силу каждого из них в отдельности. Некоторые ненавидели математику, которая заставляла их прийти сюда, другие боялись ее; а были и такие, кто преклонялся перед этой математикой, потому что, положась на нее, можно было не думать, можно было заглушить в себе всякое чувство. Если землей владел банк или трест, посредник говорил: банку, тресту нужно то-то и то-то; банк, трест настаивает, требует... - словно банк или трест были какие-то чудовища, наделенные способностью мыслить и чувствовать, чудовища, поймавшие их в свою ловушку. Они, агенты, не отвечали за действия банков и трестов,- они были всего лишь люди, рабы, а банк - он и машина, он и повелитель. Кое-кто из агентов даже гордился тем, что они в рабстве у таких холодных и могучих повелителей. Агенты сидели в машинах и разъясняли людям: вы же знаете, земля истощена. Сколько лет вы здесь копаетесь, и не запомнишь.
Да. Девопс - это про то, как если программисты будут не только программировать, но ещё и деплоить, и мониторить, ещё куча всего, тогда результат получится более лучше благодаря наличию у этих людей более полной картины происходящего. Спрашивайте, если ещё глупые вопросы есть.
Сформулируете концептуальное ограничение? Типа: "показать все реализации интерфейса на одной диаграмме - бессмысленная затея, никто и никогда не должен этого хотеть".
@startuml
title Classes - Class Diagram
interface Service
class ServiceA implements Service
class ServiceB implements Service
class ServiceC implements Service
class ServiceD implements Service
class ServiceE implements Service
class ServiceF implements Service
class ServiceG implements Service
class ServiceH implements Service
class ServiceI implements Service
class ServiceJ implements Service
class ServiceK implements Service
class ServiceL implements Service
class ServiceM implements Service
@enduml
А какой смысл этой диаграммы? К сожалению, это как раз пример очень перегруженной диаграммы, смысл которой не ясен совсем. Это тоже самое, что взять продовую базу с 10^5 таблиц и сгенерировать таблицу связей.
Да ну. Развесистые диаграммы бывают. С ними всё в порядке. Они полезный инструмент для "творческих" задач - когда толком не знаешь где начало, где конец, но хочешь посмотреть, пообсуждать. В таких ситуациях удобны срезы всей системы целиком. Берёшь такую диаграмму, и погнал: зачёркиваешь, исправляешь, добавляешь, и т.д.
И неразвесистые диаграммы тоже бывают. Они полезный инструмент для более конкретных вопросов, типа "а как у нас классы и студенты связаны"? А вот вам картинка из 3 прямоугольничков: классы-энроллменты-студенты. На всю базу нет смысла смотреть.
Потребности "пользователей" определяют какие диаграммы имеют ценность, а какие нет. Уж точно мнение PlantUML по этому вопросу не имеет веса.
Хорошие диаграммы - это sequence диаграммы, state диаграммы. Что отображено в статье.
Sequence диаграммы хорошо идут, потому что там компоновка совершенно предсказуемая. Любой другой тип, где в общем случае дерево/граф - и всё, "3 прямоугольничка должно быть достаточно каждому". Я ж вроде это и написал в первом комментарии?
По-моему вы просто "для людей" натягиваете на технические ограничение инструмента. В зависимости от конкретной ситуации и двух прямоугольничков может быть много и тридцати мало.
Я раньше тоже избегал мышкой рисовать, но после пары реальных попыток использовать PlantUML, понял, что взять и передвинуть мышкой - это всегда одинаково предсказуемо, а учить десятки хитрых параметров PlantUML - просто специальная олимпиада какая-то.
В итоге использую https://www.diagrams.net/ - он позволяет сохранять диаграммы как XML файлы (ну и дальше их конечно же можно в гит).
Если бы всё было так просто, электронные музыкальные инструменты (ЭМИ) работали бы на генераторах синуса.
Вы конечно понимаете, что примерно половина этого брутального пульта - это тупо параметры A, B, C, D, E от примитивной функции вроде s(t, f)=A*sin((B*f+C)*t)*D*sin(E*t) ?
Почему она тогда влияет на звучание струн в электромагнитный датчик в этом опыте?
Дизайн вашего опыта не соответствует заявленной цели, потому что звучание электрогитары определяется всей той цепочкой, которую я написал выше, а вы от этой цепочки берёте только маленькую часть и делаете необоснованное предположение, что вот эта маленькая часть делает наибольший вклад в звучание, и поэтому в первую очередь нужно измерять именно её. Есть у вас там измеримая разница или нет - это не имеет значения, если итоговый вклад древесины составляет 0.01%.
Насчёт генератора синуса очень большие сомнения. Попробуйте сами его включить в электрогитарный тракт. Получится ли гитарный сигнал?
Цель моего исследования — ... изучение факторов, влияющих на звучание электрогитары.
Струны, датчики, положение датчиков относительно струн и относительно бриджа, дисторшны с прочими примочками, кабинет(ы), микрофон(ы), которым(и) вы этот(эти) кабинет(ы) пишете, расположение микрофона(-ов) относительно кабинета(-ов), акустика помещения, сведение звука из микрофонов. Древесина не влияет вообще никак. Можете вместо гитары ко всему этому тракту генератор синуса подключить, будет совершенно электрогитарный звук. Всякие там "оттенки" предсказуймее получить засчёт эквалайзеров/компрессоров, чем засчёт сортов древесины.
В каждом топике про фейл большой компании одни и те же комментарии: попытка представить большую компанию как одного недостойного человека. Не надоело?
Автор, вот вы написанное как читаете? "Провели эксперименты с пятьдесят домашних кошек"? Ну "с пятьюдясятью домашними кошками" же.
Есть программисты и есть женщины-программисты.
А не фейк? В 1907 смешное слово guaRARAnteed.
Да. Девопс - это про то, как если программисты будут не только программировать, но ещё и деплоить, и мониторить, ещё куча всего, тогда результат получится более лучше благодаря наличию у этих людей более полной картины происходящего. Спрашивайте, если ещё глупые вопросы есть.
Было бы здорово написать пару слов о том, что это за сервис.
Сформулируете концептуальное ограничение? Типа: "показать все реализации интерфейса на одной диаграмме - бессмысленная затея, никто и никогда не должен этого хотеть".
Вот исходник моей демонстрационной диаграммы:
Покажете как круглый лэйаут сделать?
Да ну. Развесистые диаграммы бывают. С ними всё в порядке. Они полезный инструмент для "творческих" задач - когда толком не знаешь где начало, где конец, но хочешь посмотреть, пообсуждать. В таких ситуациях удобны срезы всей системы целиком. Берёшь такую диаграмму, и погнал: зачёркиваешь, исправляешь, добавляешь, и т.д.
И неразвесистые диаграммы тоже бывают. Они полезный инструмент для более конкретных вопросов, типа "а как у нас классы и студенты связаны"? А вот вам картинка из 3 прямоугольничков: классы-энроллменты-студенты. На всю базу нет смысла смотреть.
Потребности "пользователей" определяют какие диаграммы имеют ценность, а какие нет. Уж точно мнение PlantUML по этому вопросу не имеет веса.
Sequence диаграммы хорошо идут, потому что там компоновка совершенно предсказуемая. Любой другой тип, где в общем случае дерево/граф - и всё, "3 прямоугольничка должно быть достаточно каждому". Я ж вроде это и написал в первом комментарии?
По-моему вы просто "для людей" натягиваете на технические ограничение инструмента. В зависимости от конкретной ситуации и двух прямоугольничков может быть много и тридцати мало.
У вас очень поверхностная статья и все примеры гладкие. Реальность выглядит например вот так:
(плагины для конфлюенсов конечно есть)
Некоторые типы диаграмм при некоторых входных данных получаются хорошие. Но в общем случае очень легко получить совершенно безумную компоновку.
Эта ссылка должна быть в статье: https://www.planttext.com/
Я раньше тоже избегал мышкой рисовать, но после пары реальных попыток использовать PlantUML, понял, что взять и передвинуть мышкой - это всегда одинаково предсказуемо, а учить десятки хитрых параметров PlantUML - просто специальная олимпиада какая-то.
В итоге использую https://www.diagrams.net/ - он позволяет сохранять диаграммы как XML файлы (ну и дальше их конечно же можно в гит).
Представляете себе как выглядит спектр синуса, пропущенного через гитарный дисторшн?
Вы конечно понимаете, что примерно половина этого брутального пульта - это тупо параметры A, B, C, D, E от примитивной функции вроде s(t, f)=A*sin((B*f+C)*t)*D*sin(E*t) ?
Дизайн вашего опыта не соответствует заявленной цели, потому что звучание электрогитары определяется всей той цепочкой, которую я написал выше, а вы от этой цепочки берёте только маленькую часть и делаете необоснованное предположение, что вот эта маленькая часть делает наибольший вклад в звучание, и поэтому в первую очередь нужно измерять именно её. Есть у вас там измеримая разница или нет - это не имеет значения, если итоговый вклад древесины составляет 0.01%.
Я-то попробовал, ваша очередь теперь :-)
Струны, датчики, положение датчиков относительно струн и относительно бриджа, дисторшны с прочими примочками, кабинет(ы), микрофон(ы), которым(и) вы этот(эти) кабинет(ы) пишете, расположение микрофона(-ов) относительно кабинета(-ов), акустика помещения, сведение звука из микрофонов. Древесина не влияет вообще никак. Можете вместо гитары ко всему этому тракту генератор синуса подключить, будет совершенно электрогитарный звук. Всякие там "оттенки" предсказуймее получить засчёт эквалайзеров/компрессоров, чем засчёт сортов древесины.
Классика же, 10 лет назад вместо Vue просто jQuery был.
Статья с подробностями на авторитетном ресурсе.
Ну вы не очень фанат просто.