Ну вот… Такой живописный эпизод хорошей книги так исковеркать, что аж вспоминается анекдот про "мне Мойша напел".
Начнем с того, что шли они не в шеренгу, а в колонну.
Кусок с походом полностью вырван из контекста. В оригинальной книге это был один из ключевых моментов изобретения техники "буфер-барабан-веревка". Почему шли, почему это важно, как реагировали дети на предложения — всё это и есть контекст.
Применять "Цель" впрямую к разработке — достаточно спорно и сложно, это сто раз обсуждено и много лет назад написаны "Цель-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.
Поддерживаю, хотя и переживаю за глаза единорога :) не поэтому ли уже пришлось очки одеть? Судя по тому как работают Ardour, JACK и все эти Catia/Claudia/LADISH, Cadence и открытые драйвера внешних многоканальных звуковых карт (а именно — изредка и вопреки здравому смыслу), единорог может заплакать.
Вот на примере этой публикации и видно почему ICO не доверяют и считают это разводом:
Из 5 примеров ни в одном нет ссылки на домашнюю страницу.
Из 5 проектов, кажется, ни один до продукта и стабильной выручки не дошёл. Ну то есть так чтобы это не было чем-то "пирамидообразным", чтобы были стабильные кастомеры и т.п.
Я не вижу и не смог найти откуда взяты оценки ICO в $. Ну в самом деле — если это долларовые оценки в какой-то криптовалюте, то в какой валюте, на какой момент курс?
Если "Filecoin" и "Status" содержат хоть какую-то конкретику, то остальные почти чисто производные от "криптовалютной" темы. А значит вне этой темы не видно монетизации, а риски впрямую связаны с рисками регулирования криптовалют.
Это только беглое прочтение, дальше просто и копать было лень.
Как выше отметили — ЗП неадекватно низкая, вот и вся аналитика из пальца. На позиции за 60 в Мск берут примерно за факт прихода на собеседование. На 80 — знает хоть что-нибудь (или не знает, но попросил 80 и вел себя адекватно). С портфолио (пусть и Потемкинская деревня), с подогнанным резюме и "был осведомлен о последних тенденциях веб-разработки, знал основные инструменты верстки и мог уверенно вести беседу о своем опыте работы на профессиональном языке" — смело надо было ориентироваться на 90-110. Тогда бы был хоть какой-то шанс увидеть технические интервью.
Короткие фиксированные спринты в scrum это очень многосторонний контракт. Судя по всему задачи большого (для scrum) объёма, соответственно команда реально ответственность не принимает, и, кстати, именно необходимость глубокой декомпозиции на целостные задачи 0,5-3 дня (5 дней в крайнем случае) является важным практическим ограничением scrum. Состав спринта менялся на ходу (и судя по всему меняется по каждому чиху).
Ретроспектива проходит с нарушениями. PO — дятел, который умеет долбить команду разработки, но не умеет работать по scrum. SM занимается не тем, чем должен. Ошибки/проблемы не обсуждаются и приоритет не согласуется. Технические решения не обсуждаются.
Технически, если из-за ошибки в third-party прикладному программисту пришлось доставать дизассемблер, чтобы спасти фичу, то это уже fail 80 lvl. С данным объёмом информации сложно сказать в чем именно fail: в архитектуре, в процессах, во взаимодействии, в компетенциях или еще в чем-то. И непонятно, можно ли его исправить (я видел как исправляли и как не исправляли).
Круто. Но это точно не конфетка.
Во второй организации непонятно, что хорошо, а что плохо, что случайно, а что систематично.
Как быстро сосчитать сумму чисел от 1 до 100? Согласно легенде, первым эту задачку решил великий немецкий математик Карл Фридрих Гаусс, еще будучи школьником.
Выкиньте на помойку свой сборник легенд.
Арифметические и геометрические прогрессии известны человечеству на несколько тысяч лет больше, чем прошло от рождения Гаусса. И формулы их сумм тоже. "По легенде" единственное в чем отличился в данном случае юный Карл Гаусс — это то что он а) решил это в то ли в 6, то ли в 7, то ли в 10 лет, б) нашёл закономерность быстрее одноклассников и неожиданно для учителя.
Этот пример мне лично не говорит о том, что "чтобы быстрее получить результат и повысить его точность, нужно автоматизировать процессы", а скорее говорит о том, что над большой задачей нужно немного подумать, и если вам повезёт, или вы гений (Гаусс, например), то может быть вы сможете найти решение не за O(N), а за O(1). А автоматизировать — это если написать программу, которая тупо складывает от 1 до 100.
Если уже привязывать Гаусса к BigData, то лучше вспомнить нормальное распределение, которое часто называют распределением Гаусса или Гаусса-Лапласа. Да, конечно, не Гаусс его придумал, но он вывел его роль в многократном измерении. Это распределение играет фундаментальнейшую роль в теории вероятностей (центральная предельная теорема). Теория вероятностей — это база для матстатистики, фактически матстатистика — задача обратная теорверу: по набору данных найти распределение. А что есть BigData, как не решение статистических задач? Так что название GAUSS для системы обработки больших данных весьма обоснованное.
Кстати, Гауссу приписывают особую внимательность к точности деталей и формулировок и к качеству своих работ. А вот если к фактам относиться, как автор этой статьи, то точность прогнозов в ВТБ будет примерно сравнима с гаданием на картах (КДПВ намекает), а обоснованность с прогнозами осминога Пауля.
PS: для выигрыша в bullshit-bingo в статье не хватает слов "Devops" и "blockchain"
Да и ещё. Вы наверное заметили, что даже если БД находится в простой модели восстановления, то транзакцию можно откатить? Так вот, при простой модели восстановления большая часть записей идёт как раз в БД tempdb. Т е интенсивность нагрузки на диски при любой модели восстановления суммарно по всем БД будет примерно одинакова.
Хм. Тут 3 не связанных утверждения, причем вместе они могут быть неверны. Сейчас поясню.
Вы наверное заметили, что даже если БД находится в простой модели восстановления, то транзакцию можно откатить?
Конечно можно! Ведь MS SQL Server устроен так, что с мелкими-мелкими оговорками он все изменения данных (практически построчно) и события начала-отмены-фиксации транзакций последовательно пишет в журнал транзакций. Причем делает это до начала выполнения следующей команды (write-ahead logging). Типичная нагрузка на ЖТ — огромное число последовательных записей небольшого размера (0,5-60 КБ) и чтения при откатах транзакций, резервном копировании, репликации и т.п. Для минимально протоколируемых операций он, правда пишет не сами изменения, а только идентификаторы страниц. Чуть-чуть это нарушается для tempdb и при Delayed Transaction Durability, но не радикально.
Так вот, при простой модели восстановления большая часть записей идёт как раз в БД tempdb.
При простой модели восстановления, и при наличии минимально протоколируемых операций, процентное соотношение записи в tempdb вырастет относительно общего количества записей, но вырастет именно на отсутвующие в журнале обычной бызы минимально протоколируемые операции.
Т е интенсивность нагрузки на диски при любой модели восстановления суммарно по всем БД будет примерно одинакова.
Да, но это только потому что минимально протоколируемые операции для усредненной OLTP БД скорее исключение, чем правило.
Между моделями восстановления simple и full по разница такая же как между bulk-logged и full и отличается только на минимально протоколируемые операции, т.е. массовую вставку в тех или иных проявлениях. Если у вас не ETL-база и не источник для отчетности, то никакой разницы на обычных операциях не будет, хотя может быть разница на регулярных обслуживаниях: alter index rebuild может быть минимально протоколируемой.
Про TSQL. С одной стороны всё так: и не найти приличных, и в вашем репозитории видно старание, аккуратность и объём проделанной работы, но… Но нельзя просто так взять и написать парсер SQL :)
15 минут посмотрел на лексер и уже вижу не менее 5 ошибок:
Спрятал тут
Идентификаторы с "[]". Закрывающая скобка может быть частью идентификатора
select 42 as [Look here []]]
Вывод
Look here []
------------
42
Числа:
select 1e -- у вас это не число
select 1e- -- у вас это не число
Пустое место. Неразрывный пробел MS SQL воспринимает как пробел. Стоит отметить, что есть и дргие "пробелы"
BINARY BASE64 воспринимается как одна лексема. Конкретный сценарий неправильного парсинга надо подбирать, но, как минимум, несколько пробелов там допустимы.
Комментарии. У вас `'/' .? '*/', а на самом деле возможны вложенные комментарии.
/* SELECT 'Hello' /* */ SELECT 'Protected by PT' --*/ SELECT 'Executed by someone'
Ваш лексер будет думать, что выведется 'Protected by PT', а на самом деле 'Executed by someone'. И эти люди защищают нас от инъекций??? Простите, не удержался :)
Это правда не более 15 минут просто посмотрев в лексер (комментарий дольше писал). В парсер даже не вчитывался. Я даже не знаю о чем это говорит (выбирайте сами):
Парсеры без ошибок писать сложно. Чертовски сложно даже для тех, кто, наверное, должен уметь писать безопасные парсеры.
Язык TSQL — ад для перфекционистов-парсерописателей.
Open-Source рулит, потому что в закрытом коде эти проблемы просто бы скрылись.
Я зануда и у меня просто глаз набит (да, я видел очень немного грамматик/парсеров, в которых бы я не находил ошибок).
PS: Правки достаточно простые, я попробую найти время на выходных для PR в github, но не обещаю.
Тут нет противоречия. Если ты выигрываешь гостендер на условный миллиард, то скрыть по-тихому выручку не получится. А вот скрыть структуру затрат — придётся обязательно.
Ну вот… Такой живописный эпизод хорошей книги так исковеркать, что аж вспоминается анекдот про "мне Мойша напел".
И еще момент. При чтении "Целей" надо понимать, что это очень-очень хороший рекламный материал к консалтингу, обучению Голдратта и к другим более сложным материалам. То, что они хорошо написаны — не отменяет их назначение (в корп. блогах на хабре тоже есть хорошие статьи)
На самом деле проблема долгого вызревания историй, она напрямую связана с большими итерациями и долгим циклом разработки, «мы долго придумываем и согласуем фичи, потому что их реализация займет год». Это такая взаимная индульгенция. За этими большими фичами теряются тонны тех мелочей, которые на самом деле и есть свидетельство качества. Дурацкое значение по умолчанию, странное поведение радиобаттонов, непоследовательные поля, необходимость три раза вводить одно и то же (вот, кстати, помню у покойного Трансаэро, кажется, всё вышеперечисленное на сайте было). Вроде и не критично, но ведь поправить каждое — реально час работы программиста. Но это не ставится в план, потому что «реализация займет год». А если процесс разработки, развертывания и эксплуатации быстрый и автоматизированный, то такие штуки могут исправляться быстро. Тогда начинается обратный процесс: «что там месяц думать, когда за это время мы три раза другое решение сможем реализвать», ну или не начинается, если проблема не в разработке в принципе. Но тогда и любые затраты на 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.
Вот на примере этой публикации и видно почему ICO не доверяют и считают это разводом:
Это только беглое прочтение, дальше просто и копать было лень.
Как выше отметили — ЗП неадекватно низкая, вот и вся аналитика из пальца. На позиции за 60 в Мск берут примерно за факт прихода на собеседование. На 80 — знает хоть что-нибудь (или не знает, но попросил 80 и вел себя адекватно). С портфолио (пусть и Потемкинская деревня), с подогнанным резюме и "был осведомлен о последних тенденциях веб-разработки, знал основные инструменты верстки и мог уверенно вести беседу о своем опыте работы на профессиональном языке" — смело надо было ориентироваться на 90-110. Тогда бы был хоть какой-то шанс увидеть технические интервью.
Короткие фиксированные спринты в scrum это очень многосторонний контракт. Судя по всему задачи большого (для scrum) объёма, соответственно команда реально ответственность не принимает, и, кстати, именно необходимость глубокой декомпозиции на целостные задачи 0,5-3 дня (5 дней в крайнем случае) является важным практическим ограничением scrum. Состав спринта менялся на ходу (и судя по всему меняется по каждому чиху).
Ретроспектива проходит с нарушениями. PO — дятел, который умеет долбить команду разработки, но не умеет работать по scrum. SM занимается не тем, чем должен. Ошибки/проблемы не обсуждаются и приоритет не согласуется. Технические решения не обсуждаются.
Технически, если из-за ошибки в third-party прикладному программисту пришлось доставать дизассемблер, чтобы спасти фичу, то это уже fail 80 lvl. С данным объёмом информации сложно сказать в чем именно fail: в архитектуре, в процессах, во взаимодействии, в компетенциях или еще в чем-то. И непонятно, можно ли его исправить (я видел как исправляли и как не исправляли).
Круто. Но это точно не конфетка.
Во второй организации непонятно, что хорошо, а что плохо, что случайно, а что систематично.
PPS: будущий «король математики» в конце VIII века — Гаусс жил на тысячу лет позднее.
Выкиньте на помойку свой сборник легенд.
Арифметические и геометрические прогрессии известны человечеству на несколько тысяч лет больше, чем прошло от рождения Гаусса. И формулы их сумм тоже. "По легенде" единственное в чем отличился в данном случае юный Карл Гаусс — это то что он а) решил это в то ли в 6, то ли в 7, то ли в 10 лет, б) нашёл закономерность быстрее одноклассников и неожиданно для учителя.
Этот пример мне лично не говорит о том, что "чтобы быстрее получить результат и повысить его точность, нужно автоматизировать процессы", а скорее говорит о том, что над большой задачей нужно немного подумать, и если вам повезёт, или вы гений (Гаусс, например), то может быть вы сможете найти решение не за O(N), а за O(1). А автоматизировать — это если написать программу, которая тупо складывает от 1 до 100.
Если уже привязывать Гаусса к BigData, то лучше вспомнить нормальное распределение, которое часто называют распределением Гаусса или Гаусса-Лапласа. Да, конечно, не Гаусс его придумал, но он вывел его роль в многократном измерении. Это распределение играет фундаментальнейшую роль в теории вероятностей (центральная предельная теорема). Теория вероятностей — это база для матстатистики, фактически матстатистика — задача обратная теорверу: по набору данных найти распределение. А что есть BigData, как не решение статистических задач? Так что название GAUSS для системы обработки больших данных весьма обоснованное.
Кстати, Гауссу приписывают особую внимательность к точности деталей и формулировок и к качеству своих работ. А вот если к фактам относиться, как автор этой статьи, то точность прогнозов в ВТБ будет примерно сравнима с гаданием на картах (КДПВ намекает), а обоснованность с прогнозами осминога Пауля.
PS: для выигрыша в bullshit-bingo в статье не хватает слов "Devops" и "blockchain"
Хм. Тут 3 не связанных утверждения, причем вместе они могут быть неверны. Сейчас поясню.
Конечно можно! Ведь MS SQL Server устроен так, что с мелкими-мелкими оговорками он все изменения данных (практически построчно) и события начала-отмены-фиксации транзакций последовательно пишет в журнал транзакций. Причем делает это до начала выполнения следующей команды (write-ahead logging). Типичная нагрузка на ЖТ — огромное число последовательных записей небольшого размера (0,5-60 КБ) и чтения при откатах транзакций, резервном копировании, репликации и т.п. Для минимально протоколируемых операций он, правда пишет не сами изменения, а только идентификаторы страниц. Чуть-чуть это нарушается для tempdb и при Delayed Transaction Durability, но не радикально.
При простой модели восстановления, и при наличии минимально протоколируемых операций, процентное соотношение записи в tempdb вырастет относительно общего количества записей, но вырастет именно на отсутвующие в журнале обычной бызы минимально протоколируемые операции.
Да, но это только потому что минимально протоколируемые операции для усредненной OLTP БД скорее исключение, чем правило.
Про TSQL. С одной стороны всё так: и не найти приличных, и в вашем репозитории видно старание, аккуратность и объём проделанной работы, но… Но нельзя просто так взять и написать парсер SQL :)
15 минут посмотрел на лексер и уже вижу не менее 5 ошибок:
Идентификаторы с "[]". Закрывающая скобка может быть частью идентификатора
Вывод
Числа:
BINARY BASE64воспринимается как одна лексема. Конкретный сценарий неправильного парсинга надо подбирать, но, как минимум, несколько пробелов там допустимы.Ваш лексер будет думать, что выведется 'Protected by PT', а на самом деле 'Executed by someone'.
И эти люди защищают нас от инъекций???Простите, не удержался :)Это правда не более 15 минут просто посмотрев в лексер (комментарий дольше писал). В парсер даже не вчитывался. Я даже не знаю о чем это говорит (выбирайте сами):
PS: Правки достаточно простые, я попробую найти время на выходных для PR в github, но не обещаю.
Тут нет противоречия. Если ты выигрываешь гостендер на условный миллиард, то скрыть по-тихому выручку не получится. А вот скрыть структуру затрат — придётся обязательно.