Очевидно, что арбалет, как устройство появилось значительно позже лука. Проблема, которую решал создатель арбалета достаточно проста и очевидна — хотелось сохранить кинетическую энергию натянутой тетивы без участия мускулатуры стрелка. В итоге арбалет получился более громоздким, менее дальнобойным, более дорогим в изготовлении, менее скорострельным, менее убойным на средних дистанциях. Лук (особенно длинный лук) уделывал арбалет по всем показателям, тем не менее, после популяризации арбалета практически все армии так или иначе использовали в первую очередь именно арбалет, а не лук. И причина этому очень простая.

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

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

Но все мы знаем, что в результате побеждает стандартизация, а не профессионализм.

#перечитываяэкстраполяцию

Задачи, о которых просят пользователи.

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

Есть две крайности, ударяться в которые будет очень плохо.

Первая крайность бездумно потакает всем похотям пользователей, конечно предварительно группирует входящие запросы по подобию. А если в команде есть бизнес-аналитик, то ещё очень быстро появляется желание оценивать полезность реквестов и отсеивать их. Мол, «удовлетворим 20% вот этих желаний, получим 80% выгоды, а на остальные подзабьём» или ещё как-то так. Принципиально аналитики картины не меняют, хотя да, эффективность повышают.

Вторая крайность говорит, что нужно вообще забить на отдельные реквесты пользователей и даже не пытаться их записывать. Те штуки, которые действительно нужно делать, будут сниться в ночных кошмарах всем членам команды. Пользователи прям достанут, умоляя сделать ту или иную фичу. Когда-то такой подход декларировала компания «Basecamp» в своей книжке «Rework», кажется.

А фишка в том, что оба подхода принципиально не верны. К пользовательским запросам нужно относиться, как к капризам и просьбам ребёнка. Когда дети хотят конфету, это скорее значит, что им надо дать каши. Это в том смысле, что комбинация из понимания потребностей пользователей, причин, вызывающих эти потребности и того, как пользователи это интерпретируют, может дать очень хорошее видение будущих фич. Но никак не прямое исполнение декларируемых желаний.

#перечитываяэкстраполяцию
_______
Source: https://t.iss.one/itextrapolation/463

Бояться надо не когда ИИ пройдёт тест Тьюринга, а когда он его намеренно завалит. И самое страшное, что понять, что это произошло мы уже не сможем.

#dimoneverything #перечитываяэкстраполяцию
_______
Источник | #itextrapolation

Чем клево число Пи? Во-первых и основных это иррациональность и трансцендентность этого числа. Технически это означает, что π нельзя представить никаким другим числом. В том смысле, что его нельзя предствить в виде корня какого-то другого многочлена с целыми коэффициентами и нельзя представить в виде дроби простых чисел (m/n). Число π бесконечно и непериодично в десятичном представлении. А это значит, что теоретически в числе π найдется любая другая подпоследовательность. Нужно только хорошо ее поискать.

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

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

Конечно же, искать подпоследовательность хотя бы в 50 мегабайт очень долго и тяжело, но вот после того, как найти такую подпоследовательность, этот файл можно выписать себе на листик в виде смещения в π и длинне подпоследовательности. Сжатие в 100%! Никаким «зипам» и «рарам» это и не снилось!

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

Ну ничего, давайте файл разобъем на более мелкие кусочки, скажем в 640 килобайт, а их уже будем прятать в π. Тогда на смещение в 640КиБ нам нужно будет потратить, скажем, 2Киб, и тогда сжатие будет не 100%, а ~99%. Звучит более реалистично и вполне реализуемо. Более того, уже даже файловая система такая есть, основанная на этом незамысловатом принципе. Работает, конечно, медленно, но работает.

github.com

#перечитываяэкстраполяцию
_______
Источник | #itextrapolation