Category: архитектура

Category was added automatically. Read all entries about "архитектура".

404

Архитектурно-философское, про best practice

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

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

Это что-то сложное - не желание изобрестать велосипед там, где его уже изобрели с одной стороны, и боязнь коммита на "создание архитектуры". Когда что-то делаешь в рамках практик, то в той или иной мере двигаешься по хорошо известной архитектуре. Часто желание не изобретать свои архитектуры звучит так: "так надо делать потому что так делать положено". Например, положено делать питоновые программы с setup.py. При использовании уже существующих практик не только заимствуется хорошая архитектура, но и часто "за бесплатно" (то есть без необходимости об этом думать специально) обеспечивается совместимость с чем-то, о чём ты даже и не знаешь в момент, когда делаешь.

Таким образом, когда оказываешься в ситуации, когда известной практики нет, ты о существовании практики не знаешь, или существующая практика не подоходит - короче, когда надо изобретать своё, в этот момент, чем больше опыта, тем острее он давит и говорит о том, какие последствия будут. Очень отдалённые и очень неприятные. Ощущение "и чем я думал, придумывая вот эту хрень?", повторяющееся несколько раз, оно очень дисциплирует.

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

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

Вот, яркий пример: ну откуда мимо пробегающий программист знает про систему /etc/nginx/sites-available/ и sites-enabled? Он идёт читать маны от nginx'а, после чего идёт и херачит всё в nginx.conf, а при переносе в продакшен сисадмины только за голову хватаются (иногда от сарказма иногда от того, что не уследили и оно пролезло в продакшен).

А ведь проблема не в том, что "программист глупый". А в том, что это устное предание. Едва ли не культурная традиция, которая витает меж сисадминами.

И в других областях то же самое - я иногда чувствую очень конкретный сарказм у программистов по мотивам написанного мною. И не потому что "плохие алгоритмы", а потому что я не соблюл очевидные (для них практики). А где я про них узнать могу-то?

Вотъ.
404

DBZ (~60)

Оно начинает напоминать OP по формату и сложности сцен, да. Однако, тут есть огромная разница - мир OP более стационарный. То есть DBZ развивается по TTGL'ной спиральке, с постоянным спауном мобов большего уровня и левелкапингом (да-да, левелкапинг изобрели не в WOW) для новых персонажей. Иногда это приводит даже к очевидным глюкам в терминологии "сильнейшего".

В OP же, наоборот, toplevel определён в первых сериях, а дальше идёт долгое и тщательное объяснение, как же охрененен toplevel. И если кто-то на 0.001% его превысит - это будет запредельное достижение. В этом смысле оно сильно напоминает ..."Замок" Кафки, потому что там Замок был с самого начала, и сквозь всю книгу герою объясняли, насколько же он идиотом был, пытаясь туда попасть - происходило это бесконечным разветвлением первой ступени: казалось, до замка три шага, нужно сделать первый шаг - чтобы его сделать нужно сделать три шага - и герой всё время болтался в районе первого шага с бесконечным дроблением. В OP примерно то же самое, только герои не болтаются в первом шаге, а таки лезут на верх, и дробится не первый, а последний шаг. И ощущается, надо сказать, это совсем иначе - в Замке герой всё время сваливался всё ниже и ниже, а в OP он стремится всё выше и выше.

PS Это чем-то напоминает теорию зубочистки у Мураками.
404

циск VS риск

─ RU.OS.CMP (2:5030/1377) ───────────────
Msg : 8184 из 8188
От : Stanislaw Kive 2:5030/750 27 мая 05, 23:26
Кому : Sergei V. Dubrov 30 мая 05, 14:03
Тема : Hовые 64-битные микропроцессоры "Эльбрус"
────────────────────────────
codepage 866
Здpаствуй, здpаствуй каpапузик Sergei!

Fri May 27 2005 18:24, Sergei V. Dubrov wrote to Sasha Shost:

SD> теперь покажи в своей исторической фразе "риск - это инструкция за такт"
SD> упоминание про кол-во транзисторов?

ну во первых - risc - это любая инструкция за одинаковое кол-во тактов.

SD> И поинтересуйся таки, сколько транзисторов было у ранних суперскаляров

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

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

это просто скаляр. тоесть, один нервный инженер в коробочке. если туда
запихнуть нескольких (больше одного) инженеров - это уже "суперскаляр".

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

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

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

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

а в риске - сидит один инженер с калькулятром, холодным пивом,
кондиционером и сотовым телефоном.

такая вот архитектура...

Stanislaw Kive.

ps. травы не дам.

* Скажем наpкотикам: У HАС ЕЩЕ ВОДКА HЕ ЗАКОHЧИЛАСЬ!
--- mobile node
* Origin: Team Beer Nevskoye (2:5030/750)