Как стать автором
Обновить
19
0
Юрий Ярош @voidnugget

Rapid Unscheduled Disassembly Expert

Отправить сообщение
SCRUM для постсовка не катит потому что

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

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

  • Зачем разделять разработчиков на тестеров и программистов — высшую и низшую касту племенного сообщества.
    У вас по идее должен быть TDD/BDD? Пускай сами для своих же задач пишут тесты…
    Вы все же там такие Agile-ные экстремалы с RAD'ом…

  • Желание компенсироваться — «быть самым главны и/или самым умным» и подсознательно разделять всех на тех кто нравится, и тех, кто не нравится, порождая грибной менеджмент и поверхностную выработку требований.
    Привет, «Грибной менеджмент» и «Охота на ведьм».

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


На самом деле V-model это не обязательно последовательный процесс, выработка требований может происходить вместе с выработкой спецификаций для интеграции — как говорится «разделяй и властвуй». Таким образом повышается приоритет приёмочного и интеграционного тестирования и их спецификации разрабатываются уже на этапе выработки требований.
В таком случае V-model легко адаптировать под простой kanban.

V-model это разработка по спецификациям, и документация ставится выше живых людей. Пока не отработан V-model, и не адаптирован под тот же lean или kanban — смысла в Scrum двигать нет. Люди просто не сработаются и не поймут чего от них хотят, а что вообще реально можно предложить клиентам.

Ставьте контроль качества выше процессов выработки персонала — тогда будет толк.

Ныть то что большая часть постсоветских хомячков пытаются адаптировать методологии разработанные для более здоровых и развитых западных социумов — бесполезно. У нас, да и в Европе, люди слишком больны для того же Scrum'a.
Ну в общем-то как раз cейсчас пишу статью «freelance — you're doing it wrong», в рамках которой описываю основные организационные и управленческие проблемы с которыми мне приходилось сталкиваться.

Если кратко, то это
  1. Дилетанство и предрассудки — заказчики/руководство не способны учится даже на своих собственных ошибках
  2. Ригидность — не способны адаптироваться к новым условиям
  3. Желание сэкономить, часто на организации труда — напрочь убивают поддержку
  4. Неспособность адекватно оценивать риски. Все риски делегируют посредникам — убивают масштабирование.
  5. Личные психологические расстройства и компенсаторные процессы:
    • Я хочу быть самым умным и/или самым главным...
    • Я хочу подчинятся...

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

Я могу продолжать, это неполный список.

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

Прочитав Лава, и Linux Device Drivers (ещё в школе, в 2008) могу с уверенностью сказать что подобные материалы служат хорошим введением, но в них мало практической пользы — что бы хорошо понимать принципы работы, нужно самому копаться в ядре и что-то писать/отлаживать руками. К сожалению подобного рода источники довольно быстро устаревают и нужно разбираться с многим по ходу дела.
Нет смысла поддерживать продукт с монолитной архитектурой, без внятных тестов и какого-либо профилирования/оптимизации. В противном случае тут больше половины нужно будет переписать подчистую, ну в общем «как всегда».

Если вам нужны гарантии качества и долгосрочной поддержки — в первую очередь стоит заняться оценкой рисков, вменяемой организацией работ и тестированием, в том числе и нагрузочным.
Довольно сыро и без тестов… есть костыли.
Я бы не стал использовать подобное решение в своих проектах.
Зачем CDN'ам CQRS-ES'ы и реактивность?
Отдавать 40Гбит DWDM'у не проблема…

Я не раздаю контент, в основном Restful API и различные конкурирующие транзакции с большой стоимостью отката и синхронизации.
У меня распределёнка и highload'ы начинаются с 10Гбит трафика, я просто сужу по своим потребностям и задачам которые приходится решать. Не могу сказать что разработку подобных решений можно назвать простой, но она и не особо отличается от разработки любых других RESTful SOA приложений, просто есть свои особенности в архитектуре, и в организации работы.

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

Нужно отличать вертикальное масштабирование от горизонтального.
Вертикальное — эффективная утилизация мощности каждой конкретной машины с минимальными издержками на коммуникацию, тут работают модели актёров и разнообразные очереди с приоритетами (типа Disruptor), sharedmem тут не обязателен так как почти все сервисы выполняются в рамках одного процесса, ну в общем по аналогии с tasklet'ами линуксовского ядра.

Горизонтальное — распределение нагрузки на несколько машин без существенного увеличения времени отклика, тут нужно понимать что всякие master-master репликации — непозволительная роскошь. У меня обычно всё сводится к Raft'у и нескольким ведомым машинам дублирующим текущие запросы посредством зеркалирования трафика. Шардинг и репликация в таких условиях решается уже на уровне приложения, и с БД совсем не нужно заморачиваться… но это тема отдельной статьи.

Обычно когда люди вспоминают о распределёнке — ни первый, ни второй тип масштабирования не реализовывается должным образом. То отклик медленный, то избыточность не там где надо… то бутылочные горлышки без профилирования, в общем больше половины проектов выглядят довольно костыльно, по этому я так и отреагировал.
Название статьи можно перефразировать как «Масштабируем Слоупочность lvl 100»

1. AMQP толст — если размер Payload'a будет меньше размера Header'а — получаем Amplification в рамках кластера / ноды, сервис ложится при первом же скачке нагрузки. Согласен с prefer ZMQ менее избыточен.

2. Масштабировать вертикально с помощью AMQP в рамках одной ноды — ересь! Сжечь, и не смотреть где прах закопают!
Реализуйте очереди обработки задач по типу Disruptor'a в рамках приложения, или используйте готовые сурогатные модели актёров по типу Greenlet'ов. Пилите SOA.

3. Хотите строить «распределённые» сервисы — проводите нагрузочное тестирование jMeter'ом и Яндекс.танком и профилируйте до потери пульса! Иначе получите бутылочные горлышки и Amplification'ы в самых не очевидных местах.
Там уже он потиху становится мейновым портом Go, так что копать смысл есть.
Спасибо большое.
А я вот думал с чего начать копаться в llgo.
Там где нельзя — просто не умеют организовывать процесс разработки и проводить нормальный анализ рисков.
+1 Табло действительно удобная штука когда данных относительно не много (до 100Гб таблички), и модель хорошо нормализирована.
У себя чаще всего использую Pentaho Mondrian + Weka (для SVM кластеризации) => отчёты в JasperReports.
Обычно на всех OLAP решениях принято ставить надпись «для Big Data», но вот почему-то я не видел OLAP'ов обрабатывающих по терабайту логов в сутки… Тем более там часто нужны различные Spatial индексы на всяких там MVP-деревьях и прочих интересностях, которые обычно недоступны простым смертным.

Чаще всего рядовые козлят логами в популярных СУБД, и это просто напрочь выносит мозг…
Проблема в том что местные B-tree индексы, при любых размерах таблиц, отчасти хранятся в памяти, с расчёта что вероятность обращения ко всем данным подлежит нормальному распределению. Профилятор конечно может там заоптимизировать индексы всякими Adaptive Radix Tree и проч. но собственно ситуацию это никак не меняет: чем выше количество инфы в таблицах — тем больше памяти кушает база. Естественно OLTP-провайдеры могут обработать местное MVCC в СУБД (контроль транзакций) на обобщённом уровне, но FullTable или Partition Scan'ы для синхронизации и пережимки журнала рано или поздно прокатывают, что приводит к диким лагам )

Использовать двумерные R-tree или многомерные X-tree индексы и т.п., которые получше подходят для таких задач, обычно не позволяет отсутствие совести разработчиков СУБД отсутствие знаний и практики в организации подобных решений. Им ничего не нужно хранить в памяти, и с range запросами они справляются на ура, так как пересчитывают все возможные пересечения множеств уже при вставке.

В MySQL вроде отдельно есть ENGINE ARCHIVE для логов с R-tree по-умолчанию, правда туда лучше писать уже обработанные данные, а актуальные продолжать держать в InnoDB etc… естественно многомерных выборок там нет.

Обработка самого whatever-SQL'я довольно медленная обычно агрегацию можно ускорить в 10-30 раз написав расширения с низкоуровневыми SIMD оптимизациями на С, возможно даже и в 100 раз с GPGPU :3

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

Ставка абстрактного разработчика в вакууме с вменяемым опытом работы в час может составить 20-30$, это ~2500-3500$ (по себе сужу). За меньшие суммы обычно работать не принято…

Проприетарщина будет дешевле пока решаете шаблонные (обобщённые) задачи.
Как только нужно будет дёргать кластерные анализы да кастомную классификацию — обычно начинается шаманизм и отсебятинка.

Лучше со старту определить требования, учитывая возможность нанять джедаев и объём информации который нужно обработать.
<rage>

ИМХО BI это магическая плюшка которую придумали маркетологи что бы можно было написать и продать кучу никому ненужного ПО, которое должно магическим образом решить очень много важных проблем… в общем что бы руководству без мозгов было на что щёлкать, да квази-графики-отчёты глядеть, что бы «деятельность имитировать» и «казаться важными», хотя на самом деле эти метрики дикий шлак и не имеют ничего общего с реальными проблемами которы. Нужно понимать потребности психологической компенсации и использовать это как возможность продажи продуктов :3

</rage>

Офисные знатоки совсем забыли что есть Microsoft Access с мифическим SQL-конструктором который отлично дружит с MySQL / PostgreSQL посредством ODBC, и ним много чего можно решить на уровне общих прикладных задач (2-3 статистических MOLAP отчёта без сложной аналитики). Офисный планктон до пол-сотни персонала такое вполне переваривает…

Для вещей посложнее есть вполне приемлемые открытые решения по типу JasperReports или Pentaho Mondrian / Weka.
Хотя большинство всей этой OLAP мути можно реализовать материализованными представлениями в БД и своими кастомными агрегирующими функциями с шахматами и поэтессами с map/reduce и GPGPU.

В проприетарщину стоит скатываться когда вам нужна вменяемая поддержка, но все задачи должны быть оч. шаблонны.
Как показывает практика кастомизация проприетарных решений без должного тестирования и организации труда тащит душу в ад чревата сложностями поддержки в долгосрочной перспективе, вплоть до хронической «одно поправили-другое отвалилось».
Вспоминаются ужасы XML-RPC over FTP в поделках умников некоторых умельцев 1С.
Прям Gophernator, я тожe испугался :3
Портировать Go в JVM или CLR нет смысла — это против парадигм самого языка.
Тем не менее GCC / LLVM порты имеют смысл, особенно вместе с peephole'ами (низкоуровневыми оптимизациями) в runtime'е.

p.s. радует недавний мердж llgo в llvm — бэнчмарки просто загляденье.
Тут под кроссплатформом подразумевались особенности целевой архитектуры процессора, а не ОС.
Для пользователей которые дальше glibc не плавают, эти все вещи выглядят довольно эфемерно.

Учитывая особенности организации различных операций, допустим различных SIMD/MIMD в x86 Cortex-m3 ARMv7 ARMv9, можно добиться очень больших приростов производительности используя конкретные решения целевой архитектуры. Поэтому разработчикам кроссплатформенных решений проще абстрагироваться под особенности каждого процессора индивидуально. Компиляторы С/C++ чаще всего либо игнорируют все эти возможности, либо компилируют под что-то одно, игнорируя возможные оптимальные решения для конкретной задачи, но работает естественно быстрее чем пустой сишный лапшекод.

Вообще знатоки разнообразных ASM'ов довольно негативно выражаются в сторону C/C++ компиляторов — слишком много лапши: там где можно 1 специфическую инструкцию — пилят десять общих, ведь так безопасней и слоупочней).

Последние версии GCC вообще много чего могут поломать при -O3.

P.S. у разных архитектур свои ASM'ы, с разными наборами команд, и возможностями.

Информация

В рейтинге
Не участвует
Откуда
Киев, Киевская обл., Украина
Дата рождения
Зарегистрирован
Активность