Дотнет у меня в тесте слил. Я смотрел на текущем релизном core. JDK какой-то из свежих 1.8
Картина та же — сходимость "как бы есть", но реально получается что-то между n*log(n)^3, n*log(n)^2, n*log(n)^2*log(log(n)) и прочими подобными вариациями. Если дать голые числа, то зависимость именно n*log(n)^3 там найти даже с подсказкой непросто.
(ИМХО) В данном конкретном случае знание оценки в O-нотации не сильно поможет тому, кто оптимизирует этот код:
Это "решето Эратосфена" не может просчитать и десяток миллионов тупо упираясь в память.
На алгоритмах "близких к линейным", т.е. все эти n*log(n) улучшение константного коэффициента даёт существенный эффект. И уж точно даже примитивная wheel optimization выиграет больше (в 3 раза от наивного обхода), чем переход от n*log(n)^3 в n*log(n)^2
Многие алгоритмы перебора или просеивания не имеют красивых и посчитанных O-оценок. Или имею, но именно O — худший случай и это какая-нибудь экспонента от полинома (привет переборщики :) ), но при применении хороших эвристик решение может быть найдено.
В теории почти всё так (с упомянутыми оговорками про то, что O — оценка сверху). Но мы же на хабре, тут на слово верят только запустив код :) Я вот решил проверить. Была открыта IDEA, поэтому на Java.
double v = 10;
double max = 5000000;
double k = 1.1;
while (v<max){
long start = System.nanoTime();
Set<String> set = compute((int) v);
long elapsed = System.nanoTime() - start;
System.out.print((int) v);
System.out.print("\t");
System.out.print(set.size());
System.out.print("\t");
System.out.print(elapsed);
System.out.println();
v = v * k;
}
(Да, я знаю про JMH, да, я знаю что замер не самый удачный)
Ну так вот. Скопировал я результаты в Excel, поигрался. Попробовал найти асимптоту. Оно как бы и находится (у меня коэффициент elapsed/(n*log(n)^3)сходится примерно в 4.5), но погрешность от GC и прочих прелестей делает слабо отличимыми nlog(n)^3 от nlog(n)^2.
А если говорить про решето Эратосфена, то классический список оптимизаций примерно такой:
Wheel optimization (в простейшем случае проверять только 6n+1, 6n-1 для чисел от 5)
Конечно перейти к BitArray / BitSet, а скорее всего самим сделать их аналоги, чтобы перейти границу в maxInt. Это не только улучшит O-оценку, но и позволит на современных машинах легко считать в лоб (в пямяти) решето примерно до 2^37..2^40 (2^33 занимает 1 ГБ). На сладкое — не нужны хеши.
В цикле for (int step = 2; step < n; step++) не надо идти до n. Достаточно до sqrt(n) (не считая, конечно, его в каждой итерации и аккуратно обработав пограничные случаи).
Этот же цикл должен идти только по простым числам.
Решето Эратосфена великолепно параллелится. Решето Аткина, кстати, параллелить сложнее. А еще в решете Аткина нужен flip которого нет в .NET BitArray (но мы же решили пилить свой класс)
На десерт можно переписать toBinaryString() без рекурсии и с более эффективным построением строки.
Казалось бы, можно предложить эти сферы Асе — ситуация win-win. Но есть одно большое возражение: заметьте, что Ася предпочла уйти в другую команду прежде, чем выяснить возможности роста в своей. Такое поведение, скорее всего, прямо говорит об отсутствии качеств, необходимых для более ответственной позиции: доверия к руководителю, активности, лояльности, умения сформулировать потребности и смелости о них рассказать.
Я его читаю и мне, может быть и неправильно, кажется, что имелось в виду «Ася должна была выяснить», «Ася должна была быть активнее и лояльнее». На месте Аси я бы от этих «кредиторов», которым «должна» бежал бы и без офферов, пока проценты на долги не придумали.
Теперь, после разъяснения, мне уже кажется, что идея в том, что «Асе и мне было бы лучше, если бы она спросила», но всё равно фразы про «активнее и лояльнее» срабатывают как триггеры.
Ну тогда, мне кажется, вы с читателями статьи на разных языках просто говорите. Мне показалась статья чересчур категоричной и из серии «сотрудник должен» и «сотрудник обязан». Ничего он не обязан в этой части.
А я всё равно буду спрашивать про возможность контр-оффера, потому что смена сотрудника на нового внешнего — это затраты 3-6 месячных ЗП (есть случаи, когда меньше, но чаще примерно такие). Если прямо сейчас вопрос можно решить за 10% этой суммы в месяц, то так точно надо сделать. Если 20% — то это разумно обсуждаемо. Что делать после контр-оффера — вопрос отдельный, но какие-то выводы и изменения делать надо.
Вот вы про взаимную честность пишете, а на самом деле уровень откровенности между вами и сотрудником в лучшем случае где-то 3-4 из 10 (на 8 он откровенен перед собой обычно, на 9 при глубоком самоанализе, на 6-7 если повезет, то с близкими людьми).
Если вы явно или неявно требуете большего («узнал о возможностях роста» и «озвучил проблемы»), то в лучшем случае получите явный отказ, а скорее всего «фигу в кармане». В большинстве случаев для достаточно сообразительных сотрудников ближние перспективы на текущем месте достаточно понятны и без явного обсуждения, что безусловно не повод для руководителя не общаться на эту тему с сотрудником. Если не подняли ЗП по результатам пересмотра в марте, то зачем ему ждать мифического октября, когда есть понимание, что можно получать больше?
Я обязательно спрашиваю увольняющегося сотрудника, готов ли он рассматривать контр-оффер или какие-то варианты, даже если не готов предложить. Реально ответ «готов рассматривать» реже чем в половине случаев. И ни в коем случае не считаю пришедших с оффером «предателями» или «всё равно неправ, так делать нехорошо». Я могу привести примеры, когда такие сотрудники потом оставались и на 3+ лет, могу привести примеры, когда получалось договориться о доведении текущих проектов до ответственных вех или до подготовки замены. В любом случае — пришёл сотрудник с оффером, значит он молодец — как минимум объективно выяснил свою стоимость. Пришёл обсудить перед тем как пойти на собеседование — я молодец, что выстроил мостик доверия, а он молодец, что решил обсудить проблемы.
Я надеюсь, что это был сарказм. Это самый отвратительный и "саботирующий" KPI из того что можно придумать.
Первое. Это не показатель продуктивности, а "штрафной" показатель. Также, как количество опозданий или количество ушедших клиентов. Это не показатель производительности совсем.
Второе. Даже как штрафной показатель это может разрушить производство ПО и ухудшить качество.
Не бывает полных, непротиворечивых и адекватных спецификаций на программу сложнее блокнота. Для блокнота, впрочем тоже не существует. Менеджмент разработки будет всеми силами всё валить на спецификацию/задание. Причем, если для исправления надо 10 минут, а для того, чтобы "отпинаться" 3 часа — будет потрачено 3 часа.
Без подробной спецификации вообще ничего не будет. Затраты на спецификацию вырастут кратно. Разработка и тестирование будут придираться к спецификации, пока она не станет неподъёмной. Затраты на составление и согласование спецификации можно смело прибавлять к стоимости и срокам.
Разработка будет оценивать задачи, превышающие некоторый достаточно примитивный порог в недостижимую стоимость. Особенно, если это новые возможности. Даже если они выполнимы. Соответственно с этого момента система развивается только заплатками, которые в лучшем случае не улучшат архитектуру (в худшем — быстро похоронят). Приоритеты и возможности развития бизнеса идут лесом.
Тестирование будет постоянно завышать приоритет найденных ошибок и выявлять много мелочи, которая на самом деле не влияет на свойства ПО, но для них это хороший и удобный способ показать, что "мы нашли 100 дефектов, а что 1 пропустили — это посмотрите какой шлак на входе".
Разработчики пишут код с ошибками. И будут писать код с ошибками. И до прода ошибки докатываются. С таким показателем оптимальная стратегия разработчика — написать как можно меньше. Через некоторое время в команде не останется тех, кто заинтересован в развитии. А если еще и наказывать новых разработчиков за ошибки старых, то вообще никого не останется.
Менеджмент разработки сделает всё, чтобы дефект было сложно зарегистрировать как дефект. "Это кривые спеки", "это код вендора", "это ошибка в библиотеке", "это нарушен пункт 182 ч. 2 тома 15 инструкции оператора". Поверьте, это проще, чем писать без ошибок. Ну и конечно, заводить дефекты может только тестировщик, у которого тоже такой же KPI :)
У сопровождения и пользователей быстро накопится много задач типа "это не дефект", которые делают их жизнь невыносимой. Но это не дефекты, нет. И скорость обработки 20 сообщений в минуту внесена в спецификацию. Пользователь не смог купить товар на сайте? Ну конечно, вот это поле обязательное, а он его заполнить не может потому что в мобильном сайте оно не отображется, но всё по спецификации!
Разработчик мягко говоря не будет заинтересован в разработке/прикручивании прозрачного мониторинга системы. В системе будут проблемы, просто о них никто не будет знать.
В следующей итерации придётся завернуть гайки, требовать обоснование оценок, которое будет дороже разработки, еженедельный разбор багтрекера на совете директоров, сравнение трекинга времени и количества закоммиченных строки кода. Добро пожаловать в ад.
1. Найти узкие звенья системы.
2. Решить, как использовать узкое звено.
3. Согласовать все остальные действия с этим решением.
4. Повысить пропускную способность узкого звена.
5. Если на предыдущем этапе узкое звено было устранено, то перейти к шагу 1.
Всё выкинули кроме п 4 (как искать, как устранять простои и непрофильную узкого этапа, как использовать ритм и целенаправленно допускать простой неузких мест).
Ну вот… Такой живописный эпизод хорошей книги так исковеркать, что аж вспоминается анекдот про "мне Мойша напел".
Начнем с того, что шли они не в шеренгу, а в колонну.
Кусок с походом полностью вырван из контекста. В оригинальной книге это был один из ключевых моментов изобретения техники "буфер-барабан-веревка". Почему шли, почему это важно, как реагировали дети на предложения — всё это и есть контекст.
Применять "Цель" впрямую к разработке — достаточно спорно и сложно, это сто раз обсуждено и много лет назад написаны "Цель-3", "Критическая цепь" и "Синдром стога сена". Более того идеи КЦ уже проникли и в PMBoK.
И еще момент. При чтении "Целей" надо понимать, что это очень-очень хороший рекламный материал к консалтингу, обучению Голдратта и к другим более сложным материалам. То, что они хорошо написаны — не отменяет их назначение (в корп. блогах на хабре тоже есть хорошие статьи)
Ну так девопс это не только, и не столько автоматизация сборки и развертывания. (Чтобы не было двоякого толкования: я под Devops понимаю примерно то, что изложено в «The DevOps Handbook» от Gene Kim. В этих терминах даже чисто технически автоматизация сборки и развертывания это меньше половины автоматизации)
На самом деле проблема долгого вызревания историй, она напрямую связана с большими итерациями и долгим циклом разработки, «мы долго придумываем и согласуем фичи, потому что их реализация займет год». Это такая взаимная индульгенция. За этими большими фичами теряются тонны тех мелочей, которые на самом деле и есть свидетельство качества. Дурацкое значение по умолчанию, странное поведение радиобаттонов, непоследовательные поля, необходимость три раза вводить одно и то же (вот, кстати, помню у покойного Трансаэро, кажется, всё вышеперечисленное на сайте было). Вроде и не критично, но ведь поправить каждое — реально час работы программиста. Но это не ставится в план, потому что «реализация займет год». А если процесс разработки, развертывания и эксплуатации быстрый и автоматизированный, то такие штуки могут исправляться быстро. Тогда начинается обратный процесс: «что там месяц думать, когда за это время мы три раза другое решение сможем реализвать», ну или не начинается, если проблема не в разработке в принципе. Но тогда и любые затраты на devops будут ненужными.
У Devops есть один необходимый показатель: time-to-market. Сколько прошло времени от идеи до продукта. Если это часы-дни, то девопс есть. Если это недели-месяц, то девопс может и есть, но не работает эффективно. Если это месяцы-год, то никакого девопса нет. Это не «достаточное» условие, но «необходимое». Если вы, предположим, вложили в девопс миллион и time-to-market улучшился с года до 11 месяцев, то вы выкинули миллион.
Остальные показатели и метрики интересны только в контексте «где болит» и «как исправить», причем, если «болит» не на критическом пути, то и приоритет исправления не высокий.
Крупные проекты ну никак не релевантны "советам как оформлять open source проект". Они скорее антипример: во-первых, они вынуждены использовать более сложную инфраструктуру просто из-за объёма фидбэка от пользователей. Во-вторых, они неповоротливы и отягощены тоннами легаси, из-за чего могут до сих пор использовать и CVS, и свои кривые системы сборки, и устаревший стандарт C++, и что угодно. В-третьих, у них свои заморочки с инвесторами. И да, от этого страдают и разработчики, и контрибуторы, и пользователи, и аудиторию они теряют — контрибутить в таких монстров хочет и может далеко не всякий. И тем не менее, зеркало на GH среди них — скорее правило, чем исключение. И почти все (их тех у кого апстрим в git) таки принимают PR.
Не совсем.
Да, есть кейсы, как с ядром линуха, но много труъ опенсорса не хостится на гитхабе вовсе не из-за объёма фидбэка от пользователей, тонн легаси и прочего. Ну в самом деле, какая очередь фидбэка в v8 или Ardour?
Из того, что я вижу основные причины в issue. Issue в github это удобно, пока busfactor==1 и не надо передавать мейнтейнерство. Вторая причина — если проект является частью большой инициативы (chromium, kde, gnu, apache и проч), тогда зеркало обычно есть, но контрибутинг через свою площадку.
И обратите внимание, что каждый отдельный реп обычно не гигантский, примеры: mousepad или gparted — небольшие, а коммитов немного (да и что там докоммичивать?). А в гигантский corefx контрибутят изо всех сил (при том, что там надо соглашение с MS подписать и требования по качеству нормальные). К слову в структуре corefx очень легко разобраться и найти нужное.
Я это всё к тому, что мир FOSS не заканчивается на github trends. Рекомендация для начала своего проекта попробовать github — отличная рекомендация (хотя, как я писал ниже gitlab мне и больше по душе). А безаппеляционное "только github, остальные маргиналы и проприерасты" — уже не отличная, потому что "остальные" себя вполне обосновано могут и мейнстримом считать.
В плане "разобраться с интерфейсом" github, gitlab и bitbucket различаются подчас меньше, чем соседние похожие проекты в jira или youtrack в одной организации.
Что биржа будет делать, если злоумышленник получил root-доступ на большинство серверов?
«Биржа» даже в России — это далеко не однородная структура: несколько юрлиц, сотни серверов, множество разных сервисов (на очень разном ПО, на разных ОС, разные MQ, разные СУБД и всё это не только X86). Поэтому «получить root-доступ на большинство серверов» весьма сложно. Если у злоумышленника настолько большие возможности, то биржа ему зачем?
Как будет обрабатываться ситуация, когда о взломе узнали спустя два-три месяца манипуляции котировками на «низком» уровне (когда разным участникам торгов отдаются разные цифры)?
Эм… Ну начнем с того, что биржа должна в итоге «смэтчить» заявки. То есть у каждого покупателя должен быть продавец с той же ценой (да, тут много оговорок, например центральный контрагент в РФ или несколько уровней брокеров, но сам мэтчинг где-то есть). И у покупателя, и у продавца, и у клиринга есть достаточно информации о сделке, чтобы проверить, что деньги не взялись «ниоткуда». Эта информация очень важна и проверяется многократно и разнообразно. Ведь именно на оборот обычно завязаны комиссии. Это топорно и выявится не «через 2-3 месяца» а примерно в ближайший клиринг.
Схемы, как например, с фронт-раннигом (когда нехороший участник транслирует дальше завышенные котировки, а сам совершает сделку по рынку, делая одновременно встречную с тем, кому транслировал некорректную котировку) обычно делаются не на бирже (там клиринг это сразу покажет), а в совершенно диких и нечестных брокерах. Этими самыми брокерами а не «хацкерами».
И пусть статья весьма «детского» уровня, но вывод в ней в правильный: какой-то компонент биржи взломать можно, но превратить это в свою выгоду (и в потери других) в целом проблематично [гораздо проще ломать других участников].
Этот абзац у автора получился самым спорным и заведомо холиварным.
Холивар svn/git/hg. При всей популярности git, на hg сидят крупные и важные проекты (JDK, Firefox), да и некоторые с svn не торопятся уйти. У hg и svn с выбором хостинга посложнее, но бросаться фразами "андеграунд, либо суровая проприетарщина" точно не стоило.
Безальтернативно "только github" тоже опрометчиво. Во-первых, есть bitbucket и gitlab, причем последний семимильными шагами наращивает функциональность. У gitlab есть в общем-то всё что и у github, но есть еще закрытые репозитории, есть встроенный CI (не wow, но для микропроектов вполне), есть возможность экспортировать проект с обвязкой типа issue и т.п. в файл и потом развернуть локально — не так страшно всё потерять.
Более того огромное количество OS-проектов НЕ хостится на гитхабе. Среди достаточно крупных и серьёзных проектов основной репозиторий на гитхабе скорее исключение, чем норма (linux kernel, kde, gnome, xfce и прочие). Скорее норма какой-нибудь gitorious локальный и списки рассылки. И, да, благодаря архитектуре git у большинства таких проектов есть R/O зеркало на github — просто потому что это легко и незатратно. Но завязывать workflow разработки на github весьма спорная идея даже для pet project.
Хотя если у разработчика есть сомнения, где же выложить свою нетленку, то github самое оно.
Если честно, то я сильно сомневаюсь, что у вас получается настроить независимо две гитары с точностью до 1/4 герца. Да, проверить это можно по частоте биений, которая будет для близких частот примерно равна их разнице. Для независимо настроенных на слух инструментов период биения в 4 секунды это прям "вау". Я когда в пределах одной гитары настраиваю пятую струну по первой или первую по пятой по резонансу третьей гармоники или по натуральному флажолету на 7 ладу, то делаю специально биения в 3 секунды (потому что квинта не ровно 1/3 грифа). У тюнеров, кстати, точность ниже. Но это на инструменте, где я точно знаю, что лады и флажолеты прям отъюстированы. И то на самом деле чуть сильнее прижать струну и будет куча других гармоник/биений.
Резонансные частоты у всех гитар разные и у всех далеко не одна. И учитывая простоту подстройки под любую базовую частоту я сильно сомневаюсь, что мнение гитар в спорах "про ля" учитывается.
Ну и разумеется, равномерно темперированный строй — хорош лишь в теории. когда вы равномерно играете в 24 тональностях. А когда у вас один ля-минор -лучше сделать строй под него.
Хм. Я вот этот абзац не понял. "Равномерно темперированный строй" это, наверное, 99% того, что можно услышать в принципе, более того почти вся современная (последние несколько веков, как подсказывает вики) музыка базируется на равномерно темперированном строе из 12 ступеней. И сам термин "ля-минор" имеет смысл в равномерной темперации, но как-то бессмысленен вне её. Может вы что-то другое имели в виду?
Разница между 440 и 432 навскидку примерно треть полутона. Если взять, например, гитару то без камертона или образца я её настраивал с точностью 1/4-1/5 полутона, но это я делал почти каждый день, это очень знакомый инструмент и это я пытался настроить правильно. Большинство моих знакомых без камертона настраивали менее точно, так что почти уверен, что значительная часть (настраиваемых) инструментов звучит дома и на репетициях черт знает где. Да что там на репетициях! Если на концерте в группе нет чего-то константного (синтезатор, например), то зачастую там плюс-минус четверть тона ошибка запросто бывает.
Из слушателей разницу между 432 и 440 заметит примерно 1 из 100.
UPD: dotnet тоже потыкал аналогично:
n*log(n)^3,n*log(n)^2,n*log(n)^2*log(log(n))и прочими подобными вариациями. Если дать голые числа, то зависимость именноn*log(n)^3там найти даже с подсказкой непросто.(ИМХО) В данном конкретном случае знание оценки в O-нотации не сильно поможет тому, кто оптимизирует этот код:
n*log(n)улучшение константного коэффициента даёт существенный эффект. И уж точно даже примитивная wheel optimization выиграет больше (в 3 раза от наивного обхода), чем переход отn*log(n)^3вn*log(n)^2В теории почти всё так (с упомянутыми оговорками про то, что O — оценка сверху). Но мы же на хабре, тут на слово верят только запустив код :) Я вот решил проверить. Была открыта IDEA, поэтому на Java.
(Да, я знаю про JMH, да, я знаю что замер не самый удачный)
Ну так вот. Скопировал я результаты в Excel, поигрался. Попробовал найти асимптоту. Оно как бы и находится (у меня коэффициент
elapsed/(n*log(n)^3)сходится примерно в 4.5), но погрешность от GC и прочих прелестей делает слабо отличимыми nlog(n)^3 от nlog(n)^2.А если говорить про решето Эратосфена, то классический список оптимизаций примерно такой:
maxInt. Это не только улучшит O-оценку, но и позволит на современных машинах легко считать в лоб (в пямяти) решето примерно до 2^37..2^40 (2^33 занимает 1 ГБ). На сладкое — не нужны хеши.for (int step = 2; step < n; step++)не надо идти доn. Достаточно доsqrt(n)(не считая, конечно, его в каждой итерации и аккуратно обработав пограничные случаи).flipкоторого нет в .NET BitArray (но мы же решили пилить свой класс)toBinaryString()без рекурсии и с более эффективным построением строки.WAT?
Метан — CH4, масса молекулы 12+1+1+1+1 = 16 ае
Углекислый газ — CO2, масса молекулы 12+16+16 = 44 ае
Закон Авогадро
Кто кого в разы тяжелее?
Я его читаю и мне, может быть и неправильно, кажется, что имелось в виду «Ася должна была выяснить», «Ася должна была быть активнее и лояльнее». На месте Аси я бы от этих «кредиторов», которым «должна» бежал бы и без офферов, пока проценты на долги не придумали.
Теперь, после разъяснения, мне уже кажется, что идея в том, что «Асе и мне было бы лучше, если бы она спросила», но всё равно фразы про «активнее и лояльнее» срабатывают как триггеры.
Надеюсь понятно объяснил, что меня напрягло.
А я всё равно буду спрашивать про возможность контр-оффера, потому что смена сотрудника на нового внешнего — это затраты 3-6 месячных ЗП (есть случаи, когда меньше, но чаще примерно такие). Если прямо сейчас вопрос можно решить за 10% этой суммы в месяц, то так точно надо сделать. Если 20% — то это разумно обсуждаемо. Что делать после контр-оффера — вопрос отдельный, но какие-то выводы и изменения делать надо.
Если вы явно или неявно требуете большего («узнал о возможностях роста» и «озвучил проблемы»), то в лучшем случае получите явный отказ, а скорее всего «фигу в кармане». В большинстве случаев для достаточно сообразительных сотрудников ближние перспективы на текущем месте достаточно понятны и без явного обсуждения, что безусловно не повод для руководителя не общаться на эту тему с сотрудником. Если не подняли ЗП по результатам пересмотра в марте, то зачем ему ждать мифического октября, когда есть понимание, что можно получать больше?
Я обязательно спрашиваю увольняющегося сотрудника, готов ли он рассматривать контр-оффер или какие-то варианты, даже если не готов предложить. Реально ответ «готов рассматривать» реже чем в половине случаев. И ни в коем случае не считаю пришедших с оффером «предателями» или «всё равно неправ, так делать нехорошо». Я могу привести примеры, когда такие сотрудники потом оставались и на 3+ лет, могу привести примеры, когда получалось договориться о доведении текущих проектов до ответственных вех или до подготовки замены. В любом случае — пришёл сотрудник с оффером, значит он молодец — как минимум объективно выяснил свою стоимость. Пришёл обсудить перед тем как пойти на собеседование — я молодец, что выстроил мостик доверия, а он молодец, что решил обсудить проблемы.
:)
Я надеюсь, что это был сарказм. Это самый отвратительный и "саботирующий" KPI из того что можно придумать.
Первое. Это не показатель продуктивности, а "штрафной" показатель. Также, как количество опозданий или количество ушедших клиентов. Это не показатель производительности совсем.
Второе. Даже как штрафной показатель это может разрушить производство ПО и ухудшить качество.
В следующей итерации придётся завернуть гайки, требовать обоснование оценок, которое будет дороже разработки, еженедельный разбор багтрекера на совете директоров, сравнение трекинга времени и количества закоммиченных строки кода. Добро пожаловать в ад.
1. Найти узкие звенья системы.
2. Решить, как использовать узкое звено.
3. Согласовать все остальные действия с этим решением.
4. Повысить пропускную способность узкого звена.
5. Если на предыдущем этапе узкое звено было устранено, то перейти к шагу 1.
Всё выкинули кроме п 4 (как искать, как устранять простои и непрофильную узкого этапа, как использовать ритм и целенаправленно допускать простой неузких мест).
Ну вот… Такой живописный эпизод хорошей книги так исковеркать, что аж вспоминается анекдот про "мне Мойша напел".
И еще момент. При чтении "Целей" надо понимать, что это очень-очень хороший рекламный материал к консалтингу, обучению Голдратта и к другим более сложным материалам. То, что они хорошо написаны — не отменяет их назначение (в корп. блогах на хабре тоже есть хорошие статьи)
На самом деле проблема долгого вызревания историй, она напрямую связана с большими итерациями и долгим циклом разработки, «мы долго придумываем и согласуем фичи, потому что их реализация займет год». Это такая взаимная индульгенция. За этими большими фичами теряются тонны тех мелочей, которые на самом деле и есть свидетельство качества. Дурацкое значение по умолчанию, странное поведение радиобаттонов, непоследовательные поля, необходимость три раза вводить одно и то же (вот, кстати, помню у покойного Трансаэро, кажется, всё вышеперечисленное на сайте было). Вроде и не критично, но ведь поправить каждое — реально час работы программиста. Но это не ставится в план, потому что «реализация займет год». А если процесс разработки, развертывания и эксплуатации быстрый и автоматизированный, то такие штуки могут исправляться быстро. Тогда начинается обратный процесс: «что там месяц думать, когда за это время мы три раза другое решение сможем реализвать», ну или не начинается, если проблема не в разработке в принципе. Но тогда и любые затраты на devops будут ненужными.
Для aphyr.com фид я не нашёл.
Остальные показатели и метрики интересны только в контексте «где болит» и «как исправить», причем, если «болит» не на критическом пути, то и приоритет исправления не высокий.
Не совсем.
Да, есть кейсы, как с ядром линуха, но много труъ опенсорса не хостится на гитхабе вовсе не из-за объёма фидбэка от пользователей, тонн легаси и прочего. Ну в самом деле, какая очередь фидбэка в v8 или Ardour?
Из того, что я вижу основные причины в issue. Issue в github это удобно, пока
busfactor==1и не надо передавать мейнтейнерство. Вторая причина — если проект является частью большой инициативы (chromium, kde, gnu, apache и проч), тогда зеркало обычно есть, но контрибутинг через свою площадку.И обратите внимание, что каждый отдельный реп обычно не гигантский, примеры: mousepad или gparted — небольшие, а коммитов немного (да и что там докоммичивать?). А в гигантский corefx контрибутят изо всех сил (при том, что там надо соглашение с MS подписать и требования по качеству нормальные). К слову в структуре corefx очень легко разобраться и найти нужное.
Я это всё к тому, что мир FOSS не заканчивается на github trends. Рекомендация для начала своего проекта попробовать github — отличная рекомендация (хотя, как я писал ниже gitlab мне и больше по душе). А безаппеляционное "только github, остальные маргиналы и проприерасты" — уже не отличная, потому что "остальные" себя вполне обосновано могут и мейнстримом считать.
В плане "разобраться с интерфейсом" github, gitlab и bitbucket различаются подчас меньше, чем соседние похожие проекты в jira или youtrack в одной организации.
«Биржа» даже в России — это далеко не однородная структура: несколько юрлиц, сотни серверов, множество разных сервисов (на очень разном ПО, на разных ОС, разные MQ, разные СУБД и всё это не только X86). Поэтому «получить root-доступ на большинство серверов» весьма сложно. Если у злоумышленника настолько большие возможности, то биржа ему зачем?
Эм… Ну начнем с того, что биржа должна в итоге «смэтчить» заявки. То есть у каждого покупателя должен быть продавец с той же ценой (да, тут много оговорок, например центральный контрагент в РФ или несколько уровней брокеров, но сам мэтчинг где-то есть). И у покупателя, и у продавца, и у клиринга есть достаточно информации о сделке, чтобы проверить, что деньги не взялись «ниоткуда». Эта информация очень важна и проверяется многократно и разнообразно. Ведь именно на оборот обычно завязаны комиссии. Это топорно и выявится не «через 2-3 месяца» а примерно в ближайший клиринг.
Схемы, как например, с фронт-раннигом (когда нехороший участник транслирует дальше завышенные котировки, а сам совершает сделку по рынку, делая одновременно встречную с тем, кому транслировал некорректную котировку) обычно делаются не на бирже (там клиринг это сразу покажет), а в совершенно диких и нечестных брокерах. Этими самыми брокерами а не «хацкерами».
И пусть статья весьма «детского» уровня, но вывод в ней в правильный: какой-то компонент биржи взломать можно, но превратить это в свою выгоду (и в потери других) в целом проблематично [гораздо проще ломать других участников].
Этот абзац у автора получился самым спорным и заведомо холиварным.
Хотя если у разработчика есть сомнения, где же выложить свою нетленку, то github самое оно.
Если честно, то я сильно сомневаюсь, что у вас получается настроить независимо две гитары с точностью до 1/4 герца. Да, проверить это можно по частоте биений, которая будет для близких частот примерно равна их разнице. Для независимо настроенных на слух инструментов период биения в 4 секунды это прям "вау". Я когда в пределах одной гитары настраиваю пятую струну по первой или первую по пятой по резонансу третьей гармоники или по натуральному флажолету на 7 ладу, то делаю специально биения в 3 секунды (потому что квинта не ровно 1/3 грифа). У тюнеров, кстати, точность ниже. Но это на инструменте, где я точно знаю, что лады и флажолеты прям отъюстированы. И то на самом деле чуть сильнее прижать струну и будет куча других гармоник/биений.
Резонансные частоты у всех гитар разные и у всех далеко не одна. И учитывая простоту подстройки под любую базовую частоту я сильно сомневаюсь, что мнение гитар в спорах "про ля" учитывается.
Хм. Я вот этот абзац не понял. "Равномерно темперированный строй" это, наверное, 99% того, что можно услышать в принципе, более того почти вся современная (последние несколько веков, как подсказывает вики) музыка базируется на равномерно темперированном строе из 12 ступеней. И сам термин "ля-минор" имеет смысл в равномерной темперации, но как-то бессмысленен вне её. Может вы что-то другое имели в виду?
Из слушателей разницу между 432 и 440 заметит примерно 1 из 100.