...

суббота, 10 марта 2018 г.

Тренинг FastTrack. «Сетевые основы». «Основы дата-центров». Часть 1. Эдди Мартин. Декабрь, 2012

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

Мы продолжаем цикл из 27 статей на основе его лекций:

Тренинг FastTrack. «Сетевые основы». «Понимание модели OSI». Часть первая. Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Понимание модели OSI». Часть вторая. Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Понимание архитектуры Cisco». Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Основы коммутации или свитчей». Часть первая. Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Основы коммутации или свитчей». Часть вторая. Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Свитчи от Cisco». Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Область использования сетевых коммутаторов, ценность свитчей Cisco». Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Основы беспроводной локальной сети». Часть первая. Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Основы беспроводной локальной сети». Часть вторая. Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Продукция в сфере беспроводных локальных сетей». Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Ценность беспроводных локальных сетей Cisco». Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Основы маршрутизации». Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Строение роутеров, платформы маршрутизации от Cisco». Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Ценность роутеров Cisco». Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Основы дата-центров». Часть 1. Эдди Мартин. Декабрь, 2012

И вот пятнадцатая из них.

Тренинг FastTrack. «Сетевые основы». «Основы дата-центров». Часть 1. Эдди Мартин. Декабрь, 2012


Зачем Cisco дата-центры? Наша компания и дата-центры – это действительно интересная история! И у меня есть воспоминания, которые могут это подтвердить. Я был парнем из IP-телефонии, специалистом в области передачи голоса, «парень-телефонист», как меня называли в моей команде, когда мы начали работать над тем, что я сосбствено называю дата-центром.

Это случилось в 2002 году, состоялось собрание нашей команды, Cisco как раз тогда объявила о приобретении компании Andiamo, и мы собирались начать продавать оптоволоконные свитчи, работающие совсем по другому протоколу, нежели Ethernet. Нас было всего 12 инженеров по программному обеспечению, они обсуждали это всё и я, откровеннно говоря, не очень слушаи их, общаясь с коллегой, и один из них сказал, что ничего не знает об этом волокне. Я повернулся и сказал, что самая важная вещь, которую нужно знать об этом, это та, что оптоволоконный кабель пишется «FIBRE», а не «FIBER». На мои слова тут же отреагировал наш старший инженер, который сказал: «О, ты, видимо, много знаешь об этом, ты настоящий специалист»! Я понял, что лучше мне было держать язык за зубами и не умничать, так как несколько следующих месяцев я выяснял, во что мы попали и как из этого «выкарабкиваться». Я должен был стать небольшим специалистом в этом, до того, как у нас появится готовая модель и все эти другие вещи, одним из тех, кто передаст эти знания своей группе.

Что я сделал. Первая вещь, которая предстояла мне, это узнать о конкурентах. Я отправился в Денвер, штат Колорадо, где собирался принять участие в мастер-классах компании McDATA. Эта компания была провайдером №1 в использовании, как они говорили, больших свитчей класса «директор». Когда я позвонил им и сказал, что я из Cisco, они ответили, что не проводят мастер-классов, в которых я могу принять участие. Вероятно, так как мы уже анонсировали о своих планах и эта компания не была сильно рада этому. Я сообщил об этом моему боссу, на что он сказал: «Я ничего не хочу знать, прояви всю свою креативность, чтобы туда попасть»! Я снова позвонил в McDATA и сказал, что я консультант, но я не могу консультировать клиентов по поводу того, в чём сам не разбираюсь. Мне ответили: «Ну что же, в таком случае у нас есть мастер-класс специально для вас»! Итак, мне пришлось снять с себя все опознавательные знаки Cisco и отправиться туда.

Я узнал там много интересного. Когда я позвонил одному из моих коллег, который занимался оптоволоконной связью, и тот спросил, что я могу сказать об этом всём сейчас, то я сказал ему, что сейчас, в 2002, чувствую себя так, словно вернулся в 1995 год. Эти свитчи имели лишь небольшой спектр опций, но это была очень надёжная и высокоскоростная связь, по меркам того времени, но внутри всех этих коробок не было никаких служб и сервисов! Я прошёл недельный курс обучения, и мы разбирали и собирали свитч серии 6140. Обучение мне очень понравилось, и в субботу я вылетел обратно. Когда я пришёл в воскресенье на работу и увидел наш новый свитч серии MDS 9500, то понял, что с таким оборудованием мы просто убьём весь рынок наших конкурентов!

В то время мы были совершенно другими людьми, мы вели совсем другие дискуссии, оптическое волокно только выходило на рынок, мы реализовывали множество новых проектов в области виртуализации, внедряли VLAN. Как раз тогда Cisco приобрела технологию VSANs (технологию создания виртуальных хранилищ), которую никто не создал до тех пор. Но как это всё мы могли объяснить? Да, мы могли сказать, что мы внедрили VSANs. Но у нас спрашивали: «Какой такой VSANs? Что за VLAN»? Люди, с которыми мы говорили, даже не знали о том, чем занимается Cisco в плане сетей. Большинство из них считало, что Cisco это компания, которая доставляет продукты для построения сетей по тому же принципу, что и компании, занимающиеся доставкой еды из магазинов. Они не знали о наших возможностях, они не знали о том, кто мы есть. И что мы сделали? Мы начали нанимать людей из различных EMS компаний по всему миру, которые занимались со всем другими вещами, и я работал с ними и другими командами, обучая их нашим премудростям. И я узнал ужасно много о дата-центрах, как о нашей будущей перспективе, оказывается, если взять общий IT-бюджет, то 60% этого бюджета тратиться в дата-центрах! Cisco не могла даже представить себе подобного! Наша компания расширялась на 45-50% в год, но мы могли «ловить только половину рыбы» в сфере организации дата-центров, поэтому решили вкладывать средства в это новое перспективное направление рынка, то есть захватить «рыбные места» и принести ценные разработки в них.

Cisco проникла на рынок дата-центров как раз перед созданием технологии виртуальных машин VMware, поэтому мы начали внедрять продукты для использования этой технологии при создании центров обработки информации. Это было наиболее удачное время и наиболее подходящая возможность для использования виртуализации. Но я хочу сказать, что мы поступили не слишком разумно, вкладывая огромные суммы в создание серверов для клиентов на протяжении последних 15 лет. Но перейдём непосредственно к нашей теме. Начнём с приложений – по степени своей важности приложения располагаются на вершине требований, предъявляемых к сетевому оборудованию. Если Вы вице-президент и Вам нужно обеспечить 12% рост своей компании без привлечения дополнительного персонала, Вам необходимо использовать более продуктивные и функциональные приложения. Сегодня Вы можете купить готовый программный продукт, сделанный на основе платформы для самостоятельной разработки приложений salesforce.com, но как поступить, если Вам нужно создать что-то уникальное для своих внутренних потребностей? Вы должны быть готовы к тому, что необходимо будет вложить много денег в разработку того, что нужно именно Вашему бизнес-проекту, но Вы сможете потом им владеть.

Пусть это будет приложение для отдела продаж. И первое, что там должно быть это база данных, в которой будут содержаться данные всех аккаунтов. И мне необходимо будет определить требованию к хранилищу, которое будет хранить и обрабатывать все эти данные, иметь возможность создания резервных копий и т.д. И для этого мне потребуется сеть, 2 свитча, которые соеденят меня с хранилищем SAN. Затем мне понадобятся серверы, которые могут быть с ОС Windows, Linux или Unix, в зависимости от прочего ПО, необходимого для работы приложений.

И если у меня есть серверы, то мне ещё понадобятся два устройства балансировки нагрузки серверов SLB и 2 файервола для защиты. И далее я должен сделать это всё доступным через IP-сеть, где каждый сможет воспользоваться этим приложением. Всё это вам необходимо, и всё это стоит денег.

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

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

Почему мы их делаем разрозненными? Контроль, решение определённой задачи, различные источники финансирования, правильно? И я могу их сделать при помощи оборудования от разных производителей. Потому что опять, тот, кто принимает решение по инфраструктуре для работы какого-то приложения, может решить на чём она будет работать. Разные типы серверов и всего остального могут потребоваться. Всё финансируется по-разному. И разные технические проблемы здесь могут быть.

SAN использует Fiber Channel Adapter Protocol для работы, который работает здесь, в адаптерах главной шины. Это решение продаётся в целостном виде. И было продано множеству производителей — EMC, HP, HDS, NetApp. Оно со временем прошло сертификацию, в нём используются свитчи Brocade или McDATA, которые стоят не больше, чем «налог». Так как стоимость такого решения может составлять 3 миллиона долларов. Никто не переживает о стоимости двух свитчей. SAN как бы заплатили «налог» за использование свитчей сторонних производителей. И применение этих свитчей обуславливалось тем, что они обеспечивали достаточно быстрое соединение серверов и хранилища. Но в хранилище не было никакой интеллектуальности. И потому им заинтересовались EMС, HP, HDS, netApp, так как 80% их дохода — это разработка приложений для существующих аппаратных решений, которые являются для них лишь путём к продаже.

И Cisco решили также принять участие. Но дело в том, что оптоволоконный протокол — «жесткий» протокол, непрощающий, гарантирующий очень быструю транспортировку огромного объёма информации в нужное место, очень крутой протокол, но совсем нетакой, как Ethernet. Когда Вы подключаетесь к оптоволоконному свитчу, происходит трёхступенчатый процесс подключения, называющийся: FLOGI (fabric login), PLOGI (port login), и PRLI (process login). Вы подключаетесь к «фабрике», волоконной сети. И если мне необходимо «представить» новый сервер в хранилище SAN для всех остальных, подключить его, все процессы останавливаются, никто не может воспользоваться сетью, пока осуществляется процесс F логин. Что происходит с приложениями? Они останавливают свою работу. Потому, если я разверну подобную инфраструктуру, я должен быть уверен, что в неё не будут добавляться никакие дополнительные серверы. Я захочу держать их независимо. Вот почему, если решение небольшое — они покупали небольшие свитчи Brocade, а для более крупных — McData. Вот и всё. Они не сильно заморачивались. 80% бизнеса McData было сосредоточено здесь, они обеспечили специальные цены и фактически ими владела EMC.

Вот почему Cisco решили принять участие, так как мы думали, что можем изменить это. Cisco принялось «раскачивать лодку», разрабатывая технологию интеллектуального процесса управления трафиком. Так как все строили эти инфраструктуры по одному типу, множество людей. Люди покупали хранилища для множества задач, подумайте только, я покупаю хранилище на 20 ТБ здесь, на 10 ТБ здесь и на 8 ТБ здесь. И какова моя утилизация этих хранилищ? 40%! Представьте, Вы приходите к CFO и говорите, мы хотим потратить ещё полтора миллиона долларов и купить ещё хранилище, так как нам нужно больше пространства, но мы утилизируем текущее лишь на 40%. Не говорите ему такого, не говорите! Это всё-равно, что купить галлон молока (3,78 литра), выпить 2 больших стакана и сказать, когда осталось более, чем половина бутылки, что нам нужно купить ещё. Нам не хочется этого делать, но это то, как эти люди делают, это неэффективно. Порты на SAN-свитчах заполнены на менее, чем 40%. Мы покупаем их, но мы их не используем.

И худшим, что могло произойти в этом случае, стало появление многоядерных процессоров в серверах. Каждые 3 года люди покупали новые серверы, обновляя старые, но новые серверы имели процессор намного более мощный, а цена оставалась прежней. Получалось, что Ваши приложения не требуют такой мощности для работы, им достаточно производительности старых процессоров, но Вы покупали новые серверы с многоядерными процессорами, которые Вы не способны были загрузить на полную мощность. Что происходило в этом случае с сервером? Его показатель утилизации падал, падала его эффективность. Мы достигли значений 10-15% на некоторых серверах, потому что развёртывали всего 1 приложение на сервере. SLB использовались на 40% мощности, файерволы на 40% мощности и так далее. Но нам нужно было иметь несколько серверов для обеспечения надёжности за счёт избыточности, а также, чтоб получить возможность масштабирования.

В то время, как свитчи LAN были утилизированы на более, чем 80%, так как мы их виртуализировали и использовали для нескольких приложений. У меня есть одно приложение и ему нужен порт, я создаю для него VLAN, потом у меня появляется второе приложение, которое также нуждается в порте и я создаю второй VLAN, преимущество этой технологии в том, что на один порт я могу назначить сколько угодно VLAN. И потому мне не нужно покупать новый свитч каждый раз, когда мне требуется новый VLAN. Мы виртуализировали это много лет назад, в средине 90-х.

Виртуализация случилась и здесь. Мы «пропихнули» эту технологию в сегмент дата-центров и назвали её «консолидацией свитчей путём виртуализации». Мы выпустили на рынок свитчи MDS 9500 и объявили клиентам, что им стоит воздержаться от покупки всей этой «мелочи», обслуживающей по одному порту. Мы предложили им приобрести одно большое устройство, которое могло создавать виртуальные сети любого масштаба, и назвали это технологией VSAN. Я объединю на рисунке три свитча SAN в один свитч VSAN.

Самая большая наша проблема не была технической, а заключалась в том, как объяснить клиентам эти технологии. И первые продажи наших свитчей начались только в декабре 2002 года. Я даже провёл двухдневный мастер-класс по организации хранилищ, чтобы объяснить преимущества использования виртуализации. И тогда VMware начал обретать популярность, некоторые из нас возможно помнят это. Тогда они, достаточно умные и бесстрашные, возможно они даже были пьяны, когда сделали это в первый раз, додумались до того, что можно виртуализировать сервер. Вместо того, чтоб исполнять одно приложение на одном сервере, мы можем загрузить программу на него, которая называется гипервизор и запустить множество приложений на одном сервере независимо друг от друга. Один физический сервер смог одновременно работать с приложениями Microsotf, приложениями Linux и программами других производителей. Раньше для этого потребовался бы отдельный сервер для Microsotf, отдельный для Linux и так далее. Тогда люди вспомнили о многоядерных процессорах и сказали: «О, вот теперь они понадобятся»! Технологию VMware стали использовать для виртуализации серверов.

Теперь рассмотрим устройства SLB, которые Cisco решила заменить модулем ACE. Этот модуль, кстати, довольно дорогой, вошёл в состав свитча Catalist 6500 и обеспечивал равномерное распределение нагрузки на сервер. ACE, Application Content Engine, расшифровывается как «движок для содержимого приложений», обеспечил балансировку нагрузки. Мы разместили в 1 свитче 50 независимых виртуальных ACE, 50 независимых балансировщиков нагрузки на одном «лезвии», и клиентам больше не нужно было покупать несколько физических SLB. Файерволы мы заменили одним модулем ASA, каждый из которых содержал до 250 виртуальных файерволов.

Каждый из виртуальных файерволов подчинялся правилам, которые Вы установили для конкретного приложения, то есть можно было защитить разными условиями 250 программ. Ну и производители хранилищ начали заменять его одним общим виртуальным пространством, VD Space.

Такая виртуализация является величайшим мировым изобретением. Мы устранили ситуацию, когда 60% бюджета IT тратилось впустую, на ненужные вещи. Повторю – мы начали с объединения физических устройств на основе виртуальных машин, чтобы затем виртуализировать весь процесс создания дата-центров. Как вы знаете, компания EMC приобрела технологию VMware и создала на её основе отдельную компанию, и Cisco была вынуждена выкупить её на IPO за 150 миллионов $. Знаете, я также вышел на IPO, но я не инвестировал 150 миллионов $, как Cisco. Я инвестировал всего лишь несколько тысяч долларов, купив несколько долей VMware. И само собой, что прийдя к ним и сказав: «Я Эдди, я хочу знать все Ваши секреты». Мне бы просто сказали: «Развернись и выходя от сюда постарайся, чтоб дверь не ударила тебя, проваливай». Вот, чтобы они сказали. Но не Cisco. Cisco пришла и сказала: «Мы инвестировали 150 миллионов $, мы владеем долей и хотим знать всё, что происходи за кулисами». И они покажут им. И потому у Cisco есть преимущество подглянуть то, куда кто идёт.

Cisco выступала «донором» для многих IT-компаний. В руководстве компании всегда были люди, которые мыслили перспективно и расширяли сферу нашего влияния, вкладывая в это средства. Эти 150 миллионов долларов не были критической суммой для Cisco, но всё равно являлись для компании значительными капиталовложениями и составляли примерно от 4 до 6% капитализации.

Внедрение виртуальных технологий проводилось с 2000 по 2003 годы. Это было первой волной создания дата-центров.

Пришло время подробно поговорить о виртуализации серверов. Я буду рассказывать Вам о вещах, которые важны лично для меня как специалиста. Предположим, у нас есть три группы, в каждой из которых есть по 2 многозадачных сервера для обработки множества приложений. Таких серверов может быть и больше, но мне не хватит доски, чтобы нарисовать их. В правой части доски нарисуем трёх разноцветных пользователей, каждый из которых использует приложения соответствующего цвета – черные, зелёные или красные. Это могут быть провайдеры интернета, компании, другие клиенты, пользующиеся сетью. Между этими людьми и серверами расположены все необходимые устройства – балансировщики трафика (SLB), файерволы и т.д. Каждый из серверов снабжён сетевой картой, которая обеспечивает 1 Гбит / с, и может быть 4, 6 или даже 8 карт в одном сервере.

С левой стороны от серверов расположено пространство сетевого хранилища (SAN). Для соединения с ним сзади наших свитчей расположены специальные сетевые карты, называемые хост-адаптерами, шины HBA, или Host Bus Adapter. Это не дешёвые модули, они стоят от 1500 до 2000 $ за каждый. Что они делают? Они как бы помещают всю поступающую от клиента информацию в капсулу, инкапсулируют её и служат для подключения сети. Такие же хост-адаптеры используют в компьютерах для обмена информацией между жёстким диском и процессором.

Внутри вашего компьютера расположен жёсткий диск, и что делает процессор, желая получить от него информацию? Он «завладевает» этим жёстким диском, подключаясь к нему через шину HBA! То же самое происходит и с сетью. Сервер хочет завладеть информацией, имеющейся в хранилище, и для этого нужны HBA. Они позволяют напрямую соединить сервер и хранилище по протоколу SCSI, которые в этом случае играют роль процессора и жёсткого диска компьютера. Между хранилищем и сервером расположены оптоволоконные свитчи, FCSW. Нарисуем их маркерами зелёного, красного и чёрного цвета.

Внутри хранилища я нарисую разноцветные массивы данных.

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

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

Итак, наш хост-адаптер HBA «капсулирует» данные и отправляет их в массив хранилища. Cisco были первыми, кто объединил все свитчи FCS в один свитч серии MDS 9500. Мы первыми придумали виртуальный процесс обмена данными между сервером и хранилищем данных, создали VSANs. Итак, Вы покупаете 2 больших свитча и любой порт может быть любым VSAN, мы виртуализировали их. Собрали всё вместе, теперь требовалось меньше устройств.

Виртуализаия началась и люди начали думать, как её применить. Представьте себе, что два верхних сервера, объединённые в «чёрную» группу, загружены всего на 10-15% от своих возможностей. Это значит, что у нас есть достаточно процессорной мощности, которая не используется. Вот тут и появляется «софт» под названием гипервизор. Если Вы загружаете это программное обеспечение VMware в сервер, то оно оптимизирует использование процессоров.

Пусть у нас в каждом сервере имеется 2 процессора по 8 ядер, итого 16 ядер, и 384 ГБ оперативной памяти. При такой загрузке у нас используется всего 4 ядра из 16 и 48 ГБ ОЗУ, а остальные 12 ядер и память простаивают. Их можно использовать для обработки других приложений, и именно этим занимается гипервизор. Я отделяю нужные нам ресурсы в отдельный сервер с 4 ядрами и 16 ГБ ОЗУ и запускаю приложение на нём. Для этого не нужно покупать никакого дополнительного «железа», гипервизор встроен в наш сервер и активируется с помощью лицензии. В этом заключается ещё одно преимущество технологий виртуализации.

Допустим, что серверы красной группы работают с приложениями, которым нужно всего 2 ядра и 64 ГБ ОЗУ, но здесь установлена другая ОС. Что я делаю? Покупаю лицензию для создания ещё одного виртуального сервера и другой операционной системы, и теперь в серверах «чёрной группы» работают 2 операционные системы, с разделёнными каналами, и вторая ОС использует 2 нужных ей ядра и 64 ГБ памяти.

Я использовал простаивающие аппаратные мощности первой группы серверов и создал внутри них виртуальный сервер с другой ОС. И теперь серверы «красной группы» мне больше не нужны – их роль играет виртуальный «чёрный» сервер, который обрабатывает приложения физических «красных» серверов! Поэтому я их просто зачёркиваю.

Примемся за третью группу физических серверов, «зелёную». Здесь занято всего 4 ядра и 32 ГБ ОЗУ. Снова покупаем лицензию, создаём виртуальный сервер внутри первой группы, предаём ему из простаивающих мощностей 4 ядра и 32 ГБ памяти, которые нужны для обработки приложений «зелёной» группы, и отказываемся от неё тоже! «Зелёных» я тоже зачёркиваю.

То, что мы сделали – величайшая вещь в мире! Клиенты имели тысячи и тысячи серверов, которые больше простаивали, чем работали. Наше решение позволило им отказаться от лишнего «железа», они стали пользоваться нашей виртуальной технологией VMware, которая обеспечила работу сервера на полную мощность, и экономили свои деньги!

Вы все знаете о системе супермаркетов Wallmart, так вот они использовали 30000 серверов в своей инфраструктуре, да, это надёжно, но не все эти серверы были распределены, более половины из них находились в одном месте — дата-центре. Представьте, что каждые 3 сервера можно заменить одним при помощи технологии виртуализации. Сколько серверов я смогу отключить? Десять тысяч! Теперь Вы видите, насколько это великая вещь? Это самое великое изобретение десятилетия! В течение многих лет компании тратили 60% бюджета на увеличение количества сетевого «железа», чтобы обрабатывать свои приложения. А сколько приложений имеется в крупных компаниях? Тысячи!

Так мы использовали свой шанс. В середине 2000-х годов мы стали продавать серверы, разработанные специально под виртуализацию. И клиенты, которые были вынуждены обновлять парк своего «железа» каждые три года, получили возможность обновлять только программное обеспечение для VMware.

Мой отец долгое время служил в армии, он прыгал с парашютом и проделывал прочие сумасшедшие вещи, так вот, он часто мне говорил: «Эдди, лучше быть удачливым, чем хорошим»! Cisco были удачливыми. Насколько это было хорошо, я не знаю.

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

Когда-то очень давно я работал в компании, где был компактный сервер Compact серии 3000, и он имел два процессора частотой по 600 МГц. Я думал, что у меня есть величайшая вещь на свете, ведь я мог обрабатывать приложения аж двумя процессорами! Но на деле оказалось, что у меня 2 процессора, а приложение не знает, как их использовать. Потребовалось сменить три поколения программ, чтоб это стало возможным. Но это дало мне возможность чувствовать какое-то время себя хорошо. Но позднее увеличилось количество ядер и вот где по-настоящему пригодилась виртуализация.

Теперь же люди смогли экономить электроэнергию и место, занимаемое лишним «железом» в стойках. Раньше клиент хватался за голову и говорил: «О Боже, есть у меня появится ещё 2 новых приложения для моего бизнеса, мне придётся строить дата-центр»! Он даже был вынужден размещать новый дата-центр не в Калифорнии, потому что здесь не было достаточного количества электроэнергии! Это правда! В этом штате летом бывают веерные отключения. Вы не сможете разместить дата-центр здесь. Теперь мы дали возможность сэкономить деньги всем этим клиентам, и это действительно круто. Вот где Cisco были удачливы. Опять же, Вы должны видеть удачу и схватить её и удержать и это сделали в Cisco.

Вернёмся к нашим пользователям в правой части доски. Предположим, «красный» клиент обменивался со своим сервером данными на скорости 6-8 Гбит/с, а теперь напрямую соединяется с нашим «чёрным» сервером. К нему добавляется ещё «зелёный» клиент со своими приложениями, которые тоже требуют своей скорости. В результате этого наш сервер, который обеспечивал 8 Гбит (6-8 линков использовались, 2 из них были для управления) и был загружен на 40%, теперь загружен более чем на 80%! Где произойдёт эффект «бутылочного горлышка»? В пропускной способности подключений. О, это отстой. Отстой для всех, но не для Cisco. Итак, как пишется Ethernet? CISCO. Какой следующий шаг после 1 Gbps Ethernet? 10 Gbps Ethernet. И потому производители серверов начали делать специальные серверы, потому, как они увидели эти узкие места также. И что они сделали? Они не стали ставить ещё больше гигабитных карт, а установили на материнскую плату ещё один модуль, который обеспечивает два 10 Гбит / с подключения, в результате чего стало возможным получить в сумме до 20 Гбит / сек или обеспечить отказоустойчивость. И так, если у нас 10 Гбит / с тут, то где нам нужно ещё обеспечить это? Внутри наших свитчей, которые расположены между этими клиентами и сервером.

А если к нам присоединится ещё один пользователь или даже несколько? Может ли Catalist 6500 выполнить эту задачу? Нет, ему не хватает на это мощности. Что мы должны сделать? Создать лучший свитч, разработать специальный проект для 10 Гбит / с подключений. Мы назвали его Nexus. Вот как появилась эта серия свитчей!

Nexus это «премиальный» сегмент свитчей, но они стоят не намного дороже серии Catalist 6500, однако обладали неоспоримыми преимуществами. Они позволили иметь множество 10 Гбит / с подключений по разумной цене. Мы выпустили Nexus 5000, 7000, но нам потребовалась большая плотность портов и мы предложили расширители «фабрики» называемые двухтысячными.

Но потом мы задумались, Ethernet произносится CISCO, мы сделали 10 Гбит / с Ehternet-подключения, но зачем нам вся эта другая оптоволоконная сеть, FCSW, работающая по другому протоколу? Для чего она нам нужна? Если кто-нибудь помнит, у IBM был такой протокол SNA, немаршрутизируемый протокол. Мы адаптировали его для наших нужд, что позволило пользователям сэкономить ещё больше денег. Cisco поступает так: мы берём один протокол, соединяем его с другим и заставляем работать в наших интересах. Это позволило нам заработать миллиарды долларов на продажах роутеров.

И Cisco сделала «коробку», к одному концу которой можно подсоединить оптоволоконный кабель, а к другому – кабель Ethernet. Нарисуем внизу трубу, или оптоволоконный канал. Она такая широкая, потому что пропускная способность оптоволокна больше, чем у 10 Гбит Ethernet. Мы поместили в неё канал меньшего диаметра, и назвали всё это FCOE, Fibre Channel over Ethernet, оптический канал сквозь эзернет. Это транспортный протокол. Благодаря ему там, где было 12 кабелей, осталось всего 2.

При этом снова произошла та же ситуация, которая возникала с другими нашими разработками. Мы внедрили эту технологию, когда для неё ещё не было стандарта, в полном объёме он был утверждён только в 2009 году. Фактически мы создали совершенно новый тип Ethernet – Эзернет для дата-центров. Это позволило отказаться от использования большей части оптоволоконных кабелей, соединяющих серверы с дата-центрами.

Можно сказать, что Cisco создали многоцелевые стандарты, которые упростили кабельную архитектуру. Почему мы так поступили? Потому, что это выделяет нас на фоне остальных. Вот на что был бы похож совершенный мир, если бы Вы начали в нём также. Мы были новичками в этой среде и мы создали MDS 9500, и мы продали их не очень много, но мы увидели, что у Nexus большие перспективы и начали работать в этом направлении и мы создали Fibre Channel over Ethernet. Который является стандартом уже долгое время. Почему мы это сделали? Потому, что мы могли продать больше Nexus свитчей. Мне это объяснил один парень из Cisco, который проработал там очень и очень долгое время и очень хорошо разбирается в бизнесе. И я попробую объяснить это Вам, использовав ещё одну демонстрационную доску, надеюсь люди в дальнем конце нашей комнаты…

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

Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас:Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?

Let's block ads! (Why?)

[Из песочницы] Дескрипторная графика в MATLAB: вторая горизонтальная ось

При изучении дескрипторной графики в MATLAB обнаружилась нехватка «юзер френдли» функционала, а именно отсутствие стандартной команды позволяющей добавить дополнительную горизонтальную ось.

Добавление дополнительной вертикальной оси, командой plotyy предусмотрено и в help к ней, в разделе topics, есть пример добавления дополнительной оси x, однако данный пример, как и сама команда, не без недостатков, что любезно сообщает нам сам разработчик фразой:

plotyy is not recommended

Разбор недостатков самой команды пожалуй опустим, а вот о недостатках указанного разработчиками примера стоит упомянуть:
  • Во-первых, нам предлагают расположить дополнительную ось в самой что ни на есть моветоновой области — в верху графика. Глаза разбегаются при попытке анализа такой картины...
  • Во-вторых, как подписывать такую ось даже продвинутому пользователю matlab может быть не ясно;
  • В-третьих, зачем нам ещё одна ось y?

Код из help
figure
x1 = 0:0.1:40;
y1 = 4.*cos(x1)./(x1+2);
line(x1,y1,'Color','r')
title('Не читаемо') % Сам вставил
ax1 = gca; % current axes
ax1.XColor = 'r';
ax1.YColor = 'r';
ax1_pos = ax1.Position; % position of first axes
ax2 = axes('Position',ax1_pos,...
    'XAxisLocation','top',...
    'YAxisLocation','right',...
    'Color','none');
x2 = 1:0.2:20;
y2 = x2.^2./x2.^3;
line(x2,y2,'Parent',ax2,'Color','k')
xlabel('f,Гц') % Сам вставил


Визуализированно распекаю пример из help
image

Для решения выше указанных проблем напишем свой код:
Решение проблем
clc
clear all
close all
%% Мои данные, возьми свои
U=[5.5 5.5 5.5 5.2 5.1 5 5 4.8 4.8]; % Значения амплитуды
F=[30 40 50 10000 12000 14000 16000 18000 20000]; % Значения частоты
[xi,ni]=find(F==50);
K=U/U(ni); % Расчёт относительных значений АЧХ
%%
figure
%% Это устанавливает шрифт и размер, речь не об этом
set(0,'DefaultAxesFontSize',20,'DefaultAxesFontName','Times New Roman');
set(0,'DefaultTextFontSize',20,'DefaultTextFontName','Times New Roman');
%% То, о чём шла речь
ax=get(axes,'Position'); % Получаю стандартное расположение осей в виде числового массива
a=gca; % Получаю свойства стандартных осей
set(a,'Position',[ax(1) ax(2)+(ax(2)/2) ax(3) ax(4)-ax(4)/10]) % Сдвигаю стандартные оси
plot(a,log(F),K,'-o'); % Строю свой график
xlim(a,[min(log(F)) max(log(F))]) % Задаю пределы своих осей
grid on % Сетка
BX=get(gca,'XTick'); % Получаю стандартную градуировку оси x в виде числового массива
BY=get(gca,'YTick'); % Получаю стандартную градуировку оси y в виде числового массива
%% Подписываю первые оси используя сдвиг
xlabel('бел','Position',[BX(size(BX,2))+1.1 BY(1)+(BY(1)/100)]) 
ylabel('K(f)')
%% Строю и подписываю дополнительную горизонтальную ось
F1=num2str(F,'%0.0i\n'); % Перевожу отсчёты предназначенные для дополнительной оси в строковый формат
ax2=[ax(1) ax(2)-(ax(2)/4) ax(3) 0]; % Задаю сдвиг относительно первых осей
b=axes('Position',ax2); % Ввожу сдвиг
xlabel('f, Гц', 'Position',[BX(size(BX,2))+1.1 BY(1)+(BY(1)/100)]) % Подписываю вторую ось
xlim(b,[min(log(F)) max(log(F))]) % Задаю пределы дополнительной оси, учитывая сдвиг
xticks(b,log(F)) % Градуирую дополнительную ось
xticklabels(b,F1) % Подписываю дополнительную ось
xtickangle(90) % Поворачиваю подпись дополнительной оси, для удобства восприятия


Давайте подробней рассмотрим некоторые элементы кода:

С помощью ниже указанной команды получаем положение осей в виде числового массива.

ax=get(axes,'Position');

Массив ax представлен в виде [a b c d], где a и b — положение левого нижнего угла графика, по горизонтали и по вертикали соответственно. Т. е. координаты начала отсчёта; с — длина горизонтальной оси, d — длина вертикальной оси.

Вводя смещения ни какое золотое сечение не вычислялось, всё «на глаз»:

set(a,'Position',[ax(1) ax(2)+(ax(2)/2) ax(3) ax(4)-ax(4)/10]) 

Так, ax(2)+(ax(2)/2) — смещает начало стандартной оси по вертикали в половину текущего, т. е. вверх от первоначального положения, что необходимо для удобочитаемости нумерованных отметок шкалы. Смещение ax(4)-ax(4)/10 задаёт размер первых осей по вертикали, т.е. уменьшает на десятую часть от текущего значения, нужно для удобочитаемости подписи графика, напомню title. Если задать d=0, то вертикальной оси попросту будет не будет видно, чем и воспользуемся в случае:
ax2=[ax(1) ax(2)-(ax(2)/4) ax(3) 0]; 

Следующий код позволяет задать положение подписей горизонтальных осей:
BX=get(gca,'XTick'); 
BY=get(gca,'YTick'); 
xlabel('бел','Position',[BX(size(BX,2))+1.1 BY(1)+(BY(1)/100)]) 
xlabel('f, Гц', 'Position',[BX(size(BX,2))+1.1 BY(1)+(BY(1)/100)]) 

Массив BX, равно как и BY, представлен как [x y], где x — положение подписи по горизонтали, y — положение подписи по вертикали.
В результате мы можем лицезреть вот такую красоту
image

Ниже оставлю пару полезных ссылок.

описание команды axes;
настройки команды axes;
команда plotyy;
метод введения дополнительной горизонтальной оси от разработчиков.

Let's block ads! (Why?)

[Перевод] Алан Кей: Будущее нельзя построить постепенно

Наименее важное время в которое мы живём — это настоящее.
Алан Кей

image

Ещё в 2014 году, когда Алан Кей выступал с этой речью в Сан Франциско, один друг присутствовал там лично. Его крайне впечатлило выступление, и он попросил перевести его для исследователя, который уже в возрасте и не знает английского. Искренне интересуясь теми, кто двигает мыслью в Долине, я согласился. Перевод лежал невостребованным долгое время, но вдруг пришла шальная мысль: взять и опубликовать.
Спасибо MagisterLudi за редакцию и помощь!

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

Большие Данные — это ниша, в которой многие сегодня пытаются делать деньги, которая также является любимицей маркетологов из-за её вездесущности. Все слышат фразу, но не все знают её значение, именно это служит отличным поводом чтобы маркетологам говорить: “это использует Большие Данные, то использует Большие Данные”. Но интересное будущее лежит за значением, за смыслом, а не данными. Стивен показал вам идею, которая у большинства людей и не появлялась — что если бы язык программирования реально знал что-нибудь о своём пользователе, о контексте, что если бы он знал бы что-нибудь и обо мне. Эти идеи довольно стары, и появились тогда, когда и многие скачкообразные открытия. Но они не были поняты в 80-е, и были просто отброшены. И это интересная тема для размышления.
Некоторое время назад Реджис МакКена (Regis McKenna), который давно засел в Силиконовой Долине, занимался PR-ом и раскручиванием, в особенности для Apple. Его достали люди, которые путают слова “инновация” и “изобретение”. Он говорил, что изобретение – это то чем занимается Xerox PARC (исследовательский центр в Пало-Альто — прим. перев.), а инновации – это то чем занимается Apple. Таким образом Xerox изобретал вещи, которые были скачками в развитии, и это был один вид работы. Вы можете это понимать как создание [“научного”] капитала (wealth), того вида капитала, который вам нужен для гидроэлектростанции или для добывания электричества из солнечной энергии. Инновации же означают конвертацию [“научного”] капитала в деньги, и это то, чем занимается Apple, совершая тем самым совсем другой вид работы, более сложный и дорогой – это заворачивание во всякие обёртки, которые нужны для постепенного внедрения изобретения в мире, преодолевая его сопротивление.

Часто, лишь толика изобретения выходит в свет


image

Потому что она выходит в мир, где возможные покупатели имеют сравнительно скудное понимание, что она из себя представляет, особенно если это что-то новое. Сегодня я буду говорить о изобретениях. Вот пример — 3333 улица Койот Хилл (адрес PARC — прим. перев.). Там был изобретён персональный компьютер (ПК), как первый Apple, Mac 1988-го или 1989-го. Но этот был собран в 1973, и мы сначала сколотили 2000 штук, потому что не возможно изобрести ПК, не имея ПК. Нужна демонстрация. Битмапный экран, графический интерфейс (GUI), — что является главным для делания денег, потому что это то, что позволяет миллиардам людей использовать компьютеры — объектно-ориентированное программирование, лазерные принтеры, Ethernet, p2p сети, и половина интернета. И многое другое. Все они были не очень похожи на то, что было до них, и мы поняли, что любое изобретение начинается не с нуля. Мы измерили разницу между изобретением и постепенным развитием (инновацией) по размеру технологического скачка. Интересно, что всё это было сделано группой из 24 человек за 5 лет, что очень дешево. В пересчёте на сегодняшний день, используя постоянный доллар, это стоило $10 миллионов в год. Конечно, тогда активы тратили совершенно по-другому: зарплаты были низкие, дома небольшие. Когда я был там, моя зарплата была $22 000, и мой дом в Пало Альто стоял на трети акра и стоил $45 000. С другой стороны, мы тратили сумму в 2-3 зарплаты на технику для каждого сотрудника, и так мы покупали дорогу в будущее. По Закону Мура, если ты сейчас хочешь что-то, что появится только через 15 лет, ты должен быть готовым платить головокружительные деньги. Поэтому наши ПК в сегодняшних долларах стояли $85 000, и мы сделали 2 000 экземпляров. Подумайте, если пойдёте в университет или компанию — они работают на компьютерах прошлого. Их шансы сделать что-то прорывное — почти ноль. Если хочешь вычислять в будущем, тебе нужно вычислять с вычислительной мощью будущего.

И вот в чём проблема: всем нравятся перемены, кроме того момента, когда эту перемену нужно совершать

image

И я не имею в виду лишь публику, я говорю о технологах. Так что пожалуй самый интересный факт о PARC, это то, что он сгенерировал 30 триллионов долларов. И это ещё одна разница между изобретением и инновацией. Люди очень радуются, когда создали компанию которая в год приносит $1 или $10 миллиардов в год, а это лишь 1/10 от 1% от $1 триллиона. А изобретение которое меняет контекст, приносит целый новый пласт технологий по прибыльности на два или три порядка выше. И изобретение позволяет инновациям иметь место: когда всё самое важное уже создано, люди могут спокойно поразмышлять над новыми идеями. Например, у парня за пару выступающих до меня были маленькие идеи, он создавал новую компанию опираясь на каждую новую идею. Это принесло ему немерено денег, а всё потому, что публика как раз таки и может переваривать лишь эти маленькие идеи. Так что самый интересный момент для нас, это то, что у технологов также были проблемы с этим. К примеру, то как мы проектировали компьютеры было отвергнуто Intel и Motorola, то как мы создавали язык программирования было отвергнуто сообществом программистов, но потому что PARC был успешным, названия тем не менее приклеивались. Например в 80х появилось много “объектно-ориентированных” (ОО) языков, которые на мой взгляд таковыми не являются (а я как раз тот кто придумал это название). C++ например не является ОО. И мы видим это повсеместно.

Люди вобщем ненавидят изучать что-то новое, и мы об этом ещё услышим через секунду, и особенно люди маркетинга этого не любят


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

У iPod-a более тупой интерфейс, чем у Mac-a. У него даже нет такой функции как “шаг назад”, хотя может быть если им потрясти, то какие то функции отзовутся для помощи. Но если думать об iPod-е как об устройстве с которым общаешься жестами, жест это то, что не только естественно, но и эффективно. Если заниматься жестами на компьютере, то корни этого процесса уходят в 60-ые, всё что тебе в реальности нужно сделать, это выучить кучу жестов на компьютере, чтобы пользоваться им бегло и эффективно, а у iPod-a нету программ обучения этим жестам. И они не заставляют разработчиков их писать. Они отупили всё до нескольких простых жестов, и такой подход выгоден для людей интересующихся деланием денег, но не для персональных вычислений.

Ещё с какой стороны можно посмотреть на это: есть “новости”, а есть “новое”


image

Что такое новость? Новость это то, что может быть рассказано за несколько минут. Почему? Потому что если вы посмотрите новость по телевизору, они не покажут вам то, что выходит за рамки категорий которые вы уже знаете. Покажут о падении самолёта, о стрельбе, и всё это впадает в категорию, о который вы уже что-то знаете. Таким образом они уходят от “нового”, которое по определению является невидимым — то, что действительно ново, ты можешь еле-еле рассмотреть. Многие люди, которые сталкиваются с чем-то действительно новым, они это либо отвергают, либо пытаются переформатировать это в то что им уже известно. Новости — это о “кострах”, вокруг которых мы собираемся и сочиняем сказки, переделываем байки в лучшие байки. Новое может занять годы изучения, чтобы понять чем оно является на самом деле. Я не могу припомнить, чтобы по новостям показывали что-то из высшей математики, чтобы помочь людям понять глобальное потепление. А при этом высшая математика известна на протяжении нескольких сотен лет, но по факту только 7% американцев брали курс по высшей математике, и только 4% понимают её. То есть это то, что не покажут по телевизору или в Нью-Йорк Таймс. И что-бы я не делал в такой-вот беседе с вами, чтобы говорить о “новом” мне приходится использовать вещи из области “новостей”. Мне необходимо использовать категории которые вы поймёте, чтобы закончить в течении оставшихся 15-и минут.

Если посмотреть на человеческую психометрику, то вот упрощённая, но всё же интересная концепция


image

Когда нечто новое появляется, 95% из нас это так-называемые “инструментальные мыслители” — люди, которые оценивают идею или инструмент на основании того, поможет-ли она им в достижении их нынешних целей. Эти люди крайне консервативны в изменении своих целей. 5% из нас реально заинтересованы в новых идеях и инструментах, и можем изменять наши цели когда эти новые вещи появляются.

image

На другой оси, 85% людей делают вещи для социального одобрения (это так-называемые экстраверты), и только 15% из нас внутренне-ориентированы. Соединяя эти две оси — они возможно не совсем независимы, но достаточно независимы для этого выступления — мы видим что только 1% из нас внутренне-ориентированы и заинтересованы в новых идеях и инструментах, а 80% консервативны, инструментальны, и направляемы мнением общественности о них. Этой группе нужно чтобы все согласились с чем-то прежде чем кто-либо согласится с чем-то. Это не происходит посредством мышления, и поэтому они не могут заниматься чем-то просто потому что это хорошая идея — у них просто нет такой категории.

image

Но если все с чем-то согласны, но при этом это ужасная идея, они будут этим заниматься и считать что это частью их культуры. Эти два квадрата объясняют многое о человеческом поведении, и оказывается что если вы хотите изменений, то вам нужно что-то делать с теми 80%, потому как тот 1% и так уже этим занят. В некоторые времена этот 1% сжигают на кострах, в 60-е их финансировали (от таких людей зародился PARC), но так или иначе эта группа всегда присутствует.

Стоит подумать и о том, что обнаружили антропологи рассмотрев 3000 традиционных культур

image

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

image

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

Как работает наш мозг


image

Мы воспринимаем зрением через глаза, и информация прыгает по мозгу из одного места в другое. Вот две концепции, показывающие что такое наш ум. Первая: это и то, что мы называем “нормальным”, наш контекст и верования, то что мы считаем реальностью. Мы считаем, что наша “норма” — эти и есть реальность, и именно поэтому нас заняло почти 200 000 лет чтобы изобрести науку. Мы думали что уже живём в своей реальности, где всё является тем, во что мы верим, и поэтому зачем искать что-то глубже? Я называю эту часть мозга призраком, т.к. в ней мы считаем что всё что нормально является реальностью. Но также временами у нас есть то что я называю “сон”, потому что по факту сознание это просто сон наяву, но более ограничено тем что происходит вокруг нас (в отличие от сна ночью когда мы не знаем, что происходит вокруг нас).

То есть мы от момента к моменту живём как бы в собственной галлюцинации


image

В доказательство вот пример: если у вас есть 2 монеты и вы знаете что они одного размера, держите одну на таком расстоянии чтобы она была в два раза дальше другой. Та, которая дальше, должна быть в половину размера той, которая ближе, но она так не выглядит. Откуда такая иллюзия? Она хорошо известна как “постоянство размера”.

image

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

image

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


Например чтение, письмо, математика, равные права — всё это изобретения, мы не запрограммированы ими от рождения. Их сложно изучать, и насколько можно увидеть, они начались примерно 13 000 лет назад, и были очень нерегулярными до недавнего времени. Например, идея как что-то пережить или вытерпеть нам хорошо известна с рождения, но идея прогресса возникла лишь в 18 веке – когда перемены были столь медленными, что все на планете умирали в той-же среде в которой рождались — это изобретение.
image

Предположим, что вы в 2 раза умнее чем Да Винчи, но родились 10000 лет до н.э. Как далеко-бы вы продвинулись? Вы бы не продвинулись вообще, вас бы скорее всего сожгли на костре. Но Генри Форд, который не был так умён как Да Винчи, родился в то время, когда знания уже были людям известны, многое уже было раскрыто, и ему не нужно было изобретать бензиновый двигатель.

image

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

Настоящее время просто ошеломляюще, потому что у нас такой маленький мозг, и мы заняты в основном настоящими (текущими) событиями

image

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

image

И именно так строились США: Томас Пэйн в работе “Здравомыслие” (Common Sense), писал “почему король должен быть законом, когда закон может быть королём?” То есть он понимал, что можно построить другую систему и провести её в закон. Увидев настоящее в таком свете, мы открываем для себя прошлое, потому что убираем особый статус той малой доли прошлого, из которой создалось наше настоящее. И это позволяет нам мечтать о том, что может быть в будущем. Открыв прошедшее, мы можем позаимствовать изобретения того времени, переработать их, и получим новые идеи, непохожие ни на что из настоящего. Но этот процесс редко используется в наши дни.

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

Мы можем делать изменения только обнаружив, что является настоящей проблемой


Человек, который хорошо этим владел, это Уэйн Гретцки, известный как самый лучший в истории хоккеист. В одном из интервью ему сказали, что он делает много бросков и промазывает, на что он ответил: “Человек промахивается на все 100% из тех бросков, которые не делает, поэтому почему бы не попытаться?” Также он сказал, что “хороший хоккеист следует за шайбой, а отличный хоккеист следует туда, где шайба окажется.” Вторая часть является новизной. И он не имел в виду оценку того, куда шайба полетит, а занять место, куда-бы ему могли сделать пас, чтобы он мог забить гол. И поэтому у него больше голов, чем у кого-либо.

В Xerox PARC, одна из игр в которую мы играли так и называлась — игра Уэйна Гретцки


image

Суть игры: зафиксировать шайбу далеко в будущем, намного дальше чем 3 месяца, как говорил предыдущий выступающий (я нашел это совершенно смехотворным). Идея-же нашей игры состояла в том, чтобы отвести шайбу на 30 лет в будущее, настолько далеко, чтобы не было известного видимого пути к этому. Таким образом в 1968 я решил, что неизбежно в будущем у нас будут ноутбуки, тому была технологическая причина, причина потребителя, и причина образования. Но играя в эту игру, надо приблизится к настоящему, и подумать какой твоя идея будет через 10-15 лет, чтобы приблизится к тому, что будет через 30 лет.

image

Такое устройство имеет железо и софт будущего, а создавать его надо уже сейчас, потому что понадобятся десятки лет, чтобы фундаментально изменить железо и софт для нового устройства. Это возможно сделать через деньги, удваивая финансирование каждые 18 месяцев — это закон Мура наоборот. И таким образом мы пришли к компьютеру Alto, предшественнику Макинтоша – он стоил $85 000 в 1973, и это была первая симуляция ноутбука. Эта машина была настолько мощной, что на ней можно было сделать всё что угодно, особенно эксперименты с интерфейсом. В наше время это одна из проблем — мы пока не знаем как разрабатывать хорошие интерфейсы, потому что с ними никто не экспериментирует. Но в Xerox PARC мы как раз таки с этим экспериментировали. И эта машина была настолько быстрой, что нам не нужно было оптимизировать, и у нас было время на пиво после обеда.

image

Возвращаясь к работе мы продолжали играть с интерфейсом. И мы создали, к примеру, Microsoft Word — он был сделан в Xerox PARCе и был протестирован на Alto в 1974, и принёс много денег Microsoft в 80-ых.

Если подумать, на самом деле всё это недорого стоит, по сравнению с тем, что мы узнаем от всего этого процесса.

Подхожу к кульминации


Уйдём в прошлое на 7 лет, это будет 2007. Что тогда было? Я хорошо помню этот год, в то время финансовое сообщество украло наши деньги. В общем 7 лет разницы во времени, как это ощущается? Не так уж давно. Но давайте посмотрим что можно было создать за те 7 лет.

Если в то время у них было планирование на 10 лет (сегодня оно может быть связано с коммуникациями, или что-то связанное с “большим смыслом”, вместо “больших данных”). Если играть в игру Уэйна Гретцки, ваше видение будет далее чем то, над чем вы реально будете работать. Из этих 10 лет, 5 лет минимум нужно отвести на исследования. Это психологически важно, потому что если вы отведёте 3 года на исследования, учёные и инженеры будут заниматься совершенно другими вещами чем те, которыми действительно нужно заниматся. Т.е. если не дать им 5 лет, то ваш проект ограничится 10-ю годами. То-же самое с горизонтом инновации для этих изобретений.

image

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

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

Кто хочет помочь с переводом полезных мыслей Алана Кея, пишите magisterludi2016@yandex.ru

Еще публикации Алана Кея на русском:

Let's block ads! (Why?)

Вынесен приговор Российским хакерам, атаковавшим американские биржи

В период с 2005 по 2012 год, группа русских хакеров взломала системы более 16 компаний и украла 160 миллионов номеров кредитных и дебетовых карт. Среди пострадавших была биржа Nasdaq, банк Citigroup, авиакомпания JetBlue, платёжная система Visa и другие, не менее крупные организации. Деятельность хакеров была названа «крупнейшей кибератакой в истории США».

Взлом Nasdaq


В октябре 2010 года была зафиксирована подозрительная пересылка данных от одного из центральных серверов электронной биржи. Оказалось, что хакеры воспользовались уязвимостями в программном обеспечении и внедрили вредоносный код. Программа была не просто шпионской: она могла не только красть информацию, но и полностью разрушить компьютерную сеть. По мнению АНБ, такая программа способна вывести из строя целую биржу.

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

Приговор


Следствие выяснило, что хакерские атаки осуществляли россияне Владимир Дринкман и Дмитрий Смилянец. В 2013 году их арестовали в Нидерландах, а потом экстрадировали в США. В 2015 году они признали себя виновными в причастности к атакам. По версии следствия, кроме них в преступлениях участвовало еще три гражданина России.

Американский суд огласил приговоры российским хакерам 14 февраля 2018 года. Владимир Дринкман был приговорён к 12 годам лишения свободы, а его сообщник Дмитрий Смилянец к 4 годам. Он уже отбыл этот срок находясь под арестом и его освободили в зале суда.

Взломы и российский финансовый рынок


В феврале 2015 года произошла атака на «Энергобанк». Хакерам удалось получить доступ к компьютеру, с которого осуществлялись сделки на Московской бирже. Вмешательство в ход торгов привело к высокой волатильности — курс доллара в течение нескольких минут колебался с 55 до 65 рублей. При том до атаки курс составлял 62 рубля и колебался на несколько копеек.

Атака длилась всего 14 минут. За это время хакеры разместили пять заявок на покупку 437 миллионов долларов и две заявки на продажу 97 миллионов. В результате неавторизованных операций банк потерял 243 млн рублей.

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

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

Для того, чтобы минимизировать возможный ущерб брокерские компании разрабатывают различные системы защиты клиентов. К примеру, такая защита есть в торговом терминале SmartX.

Другие материалы по теме финансов и фондового рынка от ITI Capital:


Let's block ads! (Why?)

6 интересных багов, с которыми я столкнулся, пока делал игру для ВКонтакте

image

Мне нравится делать игры, это мое хобби. В общей сложности около года в свободное время я делал игру на javascript для ВКонтакте. В настоящее время игра доделана, запущена, прошла модерацию ВКонтакте и доступна в каталоге игр. Это не статья вида “как я сделал игру”, а рассказ о тех проблемах, с которыми я столкнулся, пока ее создавал. Надеюсь, кому-то данная информация поможет избежать сложных ситуаций в своих проектах. Знай я о некоторых багах заранее, было бы гораздо проще, и, возможно, я бы принимал другие решения относительно кода. Добро пожаловать под кат за подробностями.

Вступление


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

image

Изначально я использовал в качестве графического движка pixi.js; позднее, по ряду причин, я решил от него отказаться и просто рисовать все на canvas. Это спорное решение, и часть описанных багов появилась именно от этого. С другой стороны, с pixi я бы получил другие сюрпризы.

Еще несколько моментов, прежде чем перейду собственно к багам.

Во-первых, хоть я использовал в заголовке слово “баг”, некоторые из описанных ниже ситуаций вовсе не баги. Это фичи, или даже правильное, но нелогичное или нестандартное поведение игры / браузера. Или просто сложности, с которыми я столкнулся.

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

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

На этом затянувшееся вступление заканчивается, переходим к сути.

№1. Танцы вокруг полноэкранного режима (fullscreen api).


И вот уже не один год прошел, как введена поддержка полноэкранного режима, а воз и ныне там. Есть много статей как в интернете, так и на Хабре, например вот. Но, по прежнему в каждом браузере делают все по своему.

Похоже сколько браузеров (ну или сколько движков), столько и вариантов названий у методов полноэкранного api.

Мало того, что сами по себе префиксы вносят неразбериху (moz, webkit). IE11 использует два префикса: ms и MS. Часть браузеров использует написание Fullscreen, часть FullScreen (привет firefox). Событие изменения полноэкранного режима пишется без заглавных букв: fullscreenchange (с префиксами, естественно). Но в IE11 оно пишется как MSFullscreenChange, в Edge — fullscreenChange.

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

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

Для интересующихся, вот результаты на CodePen. Проверено в chrome, yandex, opera, firefox, IE11. К сожалению, не имею возможности проверить в safari и edge, если кто-то может это сделать, отпишитесь в комментах.

№2. Исчезающая тень (context.shadowBlur).


При наведении мыши на фигуру, она подсвечивается с помощью добавления тени. То есть к обычной картинке я добавляю такую тень:
context.shadowBlur = 5
context.shadowColor = “#000”

У всех фигур это работает отлично, кроме обычного прямоугольника. У него тень не появляется.

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

Долгие часы поисков, проб разных вариантов, и в результате я выяснил только вот что:

  • тень на самом деле появляется, но её не видно из под картинки прямоугольника, поскольку отсутствует отрисовка Blur, то есть размытости
  • если задать тени offset, то её будет видно как положено со смещением, но, опять же, без Blur
  • такой эффект наблюдается только в прямоугольной фигуре, все остальные с тенью дружат хорошо
  • если прямоугольник повернуть на любой угол, отличный от нуля, то тень отображается нормально
  • непосредственно перед выводом на контекст изображения прямоугольника, значение shadowBlur равно пяти, как и должно быть, но отображения Blur все равно нет
  • ни одна попытка повторить этот баг отдельно от игры, в отдельном файле, не увенчалась успехом

Все фигуры выводятся на экран одним и тем же кодом, значит дело не в коде. С другой стороны, никак не получается воспроизвести этот баг вне кода игры, значит дело в коде.

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

Но я знаю, как сделать костыль и пофиксить его. Что я сделал. Открыл картинку прямоугольника в графическом редакторе, выбрал один пиксель (в углу, ну тут не принципиально я думаю), и сделал ему прозрачность не 255, а 254. В итоге картинка внешне никак не отличима от оригинала, а тень, то есть Blur, волшебным образом отображается. И не спрашивайте меня, как я это придумал.

№3. Баг с декодированием звуков (decodeAudioData)


Для воспроизведения звуков в игре я использую AudioContext. Звуки загружаются через XMLHttpRequest, затем декодируются с помощью функции decodeAudioData. Все штатно.

Через некоторое время я взялся протестировать игру на стареньком ноуте, на котором еще стоит XP и, соответственно старая версия Chrome. Вот тут то я и получил ошибку следующего вида: Uncaught (in promise) DOMException: Unable to decode audio data. Та же ошибка возникает в yandex браузере.

image

Самое интересное в этом баге то, что мне не удалось его предсказать заранее. Можно проверить поддержку аудио-контекста просто проверив его существование: window.hasOwnProperty("AudioContext"). Но как проверить можно ли декодировать звук, кроме как попытавшись его декодировать?

Также не помогает конструкция try — catch. Поскольку ошибка возникает не в js скрипте, а в коде браузера, то он просто выдает исключение и останавливает работу скрипта.

Оказалось, что ошибка возникает при попытке декодировать wav файл с одним каналом. Если конвертировать файл в двухканальный или записать в mp3, то баг пропадает.

В последних версиях chrome данный баг отсутствует.

№4. Beforeunload и сохранение данных.


При выходе из игры, в обработчике события beforeunload, я отсылаю запрос к серверу, чтобы сохранить последний открытый уровень.

Примерно в 50% случаев, а может и чаще, данные не сохранялись. Потратив некоторое время на раздумья о том, какое время дает браузер на обработку события beforeunload, и за какое время сервер обрабатывает запрос, я понял, что дело вообще не в этом. Ответ оказался простым, если его уже знаешь. Нужно использовать синхронный запрос к серверу, а не асинхронный.

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

Ну а вот то самое место, где можно (и нужно!) использовать синхронный запрос! При этом выполнение скрипта приостанавливается, beforeunload ожидает и не возвращает результат, таким образом данные успевают сохраниться.

P.S. В итоге всё же сделал сохранение после каждого уровня, так надёжнее.

№5. Canvas + Text + Firefox


Опять довольно старый баг движка gecko, о котором я заранее не знал, а зря. При выводе текста на canvas в firefox, текст отображается на несколько пикселей выше, чем в других браузерах (движках). Особенно это заметно, если использовать свойство context.textBaseline = "top". Визуально это выглядит примерно так:

image

Смещение зависит от размера шрифта, т.е. оно не одинаково. При использовании других значений context.textBaseline смещение меньше, но все равно заметно на глаз: пара пикселей при размере шрифта ~20.

Обсуждение этого бага можно почитать тут.

Что я пробовал:

  • использование context.textBaseline = “middle” и смещение текста вниз на половину высоты; как уже сказал выше, все равно есть небольшое несоответствие.
  • определять высоту текста вручную попиксельно; т.е. берем какую-либо большую букву / цифру (например 0 или Т), сверху и снизу по центру начинаем проверять пиксели, пока не встретим закрашенный; таким образом определяется высота шрифта и можно вывести надпись точно в то место, куда хотим. Но, это довольно сложно, затратно по ресурсам, возникают трудности с выводом многострочного, подчеркнутого, зачеркнутого текста. Также метод может не подходить к разным шрифтам, у которых буквы наклонены, либо имеют нестандартное начертание.
  • смещение текста на вычисляемое значение, процент от размера или типа того; не работает, т.к. нет прямой зависимости между размером шрифта и его смещением, во всяком случае я ее не знаю.

В итоге решал эту проблему “в лоб”: определял движок браузера и в случае необходимости смещал текст вниз на нужное расстояние вручную для каждой отдельной надписи. Как не странно, так оказалось проще всего.

№6. Внезапный mouseout


Думал писать ли про этот баг или нет, т.к. отловить его довольно сложно, я даже сомневался не показалось ли мне. Но в браузере vivaldi, которым я довольно активно пользуюсь, баг ловится стабильно. Также удавалось поймать его в chrome (но это не точно!). В firefox и opera добиться появления бага не удалось, но может плохо пытался.

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

Потестировать, есть ли у вас этот баг, можно тут.

Повторюсь, баг более-менее уверенно ловится в vivaldi (после 5 — 30 нажатия), неуверенно в chrome. В других браузерах поймать баг мне не удалось.

Суть тестирования: откройте pen, откройте консоль (F12), теперь наведите мышь на параграф с надписью и начинайте последовательно кликать мышью, стараясь при этом ею не шевелить. Следите за сообщениями консоли. После определенного количества кликов промелькнет надпись out, т.е. возникло событие mouseout. Удается добиться даже эффекта, что возникло событие mouseout, курсор мыши изменился на defаult, после этого достаточно малейшего шевеления мыши для того, чтобы снова возникло событие mouseover и курсор изменился на pointer.

Пробовал использовать события mouseenter / mouseleave; тестировать файл локально; отключать выделение по клику. Результаты плюс минус те же.

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

Ещё несколько


Хоть и указал в заголовке цифру 6, но вспомнил ещё пару забавных ошибок. О них кратко, много писать вроде и нечего.

Известно, что метод context.drawImage можно вызывать с разным количеством аргументов. В том числе, есть возможность указать размер области, которую мы хотим скопировать из источника и нарисовать на контексте. Так вот, в chrome можно нарисовать область размером 0x0, а firefox при этом выдаст ошибку — будет ругать за неправильный размер.

Странный баг с кодом вида

bounds = {
                                
  left: 0
  right: GAME_WIDTH
  top: 0
  bottom: GAME_HEIGHT                   
}

Вроде все хорошо, но почему то bounds.top далее в коде равняется не 0, а что-то вроде 1e-14, что конечно очень близко к нулю, но все же не 0. И если ниже в коде идет сравнение с нулем, то результат уже будет другой.
Странности тут две. Во-первых, этот баг возникает только после сборки кода в один файл с помощью require.js; пока код находится в разных модулях — файлах, такого поведения я не замечал. Во-вторых, почему то такая странность возникает только со значением top, в то время как bounds.left по прежнему строго ноль.

Спасибо!


На этом всё, больше ничего не вспомнил. Если кто-то захочет посмотреть результат работы, оценить и потестировать, проходите сюда.

Спасибо за внимание, надеюсь кому-то данная информация окажется полезной!

Let's block ads! (Why?)

Задача про forEach(ps::println) от СКБ Контур

[Из песочницы] Копирование данных с веб-сайта с помощью R и библиотеки rvest

Подвесные топливные баки для самолётов

Введение


Часто, для обеспечения большой дальности полета, к самолету снаружи подвешивают дополнительные баки. Подвесные баки бывают сбрасываемые и не сбрасываемые.

Сбрасываемые подвесные баки после расходования из них топлива сбрасываются так же, как и авиационные бомбы с замков бомбодержателей, на которые они подвешиваются.

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

Интересным фактом является то, что во вьетнамских джунглях после войны стали находить много сброшенных американскими самолётами топливных баков.

Крестьяне распиливают баки вдоль и получаются две лодки. Такая лодка не ржавеет, мало весит, а благодаря аэродинамической форме на ней очень легко грести.


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

Аэродинамическое сопротивление (АС) подвесного топливного бака


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

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

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

Аэродинамическое сопротивление Fa характеризуют безразмерным аэродинамическим коэффициентом сопротивления Cx:

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

Компоновка подвесного топливного бака из тел вращения по критерию минимума площади S и коэффициента Cx


Воспользуемся данными по расчету коэффициента лобового сопротивления (Cx) простых тел и сравнением полученного результата с экспериментом приведенными в публикации [1]:

Для тел вращения, расположенных на концах бака с цилиндром между ними (для удержания основной массы топлива), объёмом площадью поверхности можно выбрать такие варианты компоновки:

конус (при H=R) –объём площадь поверхности

конус (при H<>R)–объём площадь поверхности

полусфера –объём площадь поверхности

Зададимся объёмом бака в 3 м3: Vb=Vps+Vc+Vk, Vb=3, определим размеры для оптимальной компоновки из следующего листинга, когда условие для минимума Cx (2h=d или H=R) не выполняются:

# -*- coding: utf8 -*-    
import numpy as np
from scipy.optimize import minimize
import matplotlib.pyplot as plt
def  objective(x):# целевая функция - площадь поверхности бака
         x1=x[0]# искомый радиус R цилиндра и основания конуса
         x2=x[1]# искомая высота H конуса, когда условие H=R  не выполняется
         x3=x[2]# искомая длина L цилиндра
         return 2*np.pi*x1**2+2*np.pi*x1*x3+np.pi*x1*((x1**2)+(x2**2))**0.5
def constraint(x): # ограничение на объём бака       
         return (2/3)*np.pi*(x[0]**3)+np.pi*x[2]*(x[0]**2)+(1/3)*x[1]*np.pi*(x[0]**2)-3
x0=[1,1,1]# начальные значения для поиска локального минимума
b=(0.0,1)# ограничение по не отрицательным значениям переменных
bnds=(b,b,b)
con={'type': 'ineq','fun':constraint}
res = minimize(objective, x0,bounds=bnds,constraints=con)
e=round(res['fun'],3)
e1=round(res['x'][0],3)
e2=round(res['x'][1],3)
e3=round(res['x'][2],3)
print ("Расчётное значение площади подвесного бака :%s"%e)
print ("Расчётное значение радиуса подвесного бака :%s"%e1)
print ("Расчётное значение высоты конуса подвесного бака :%s"%e2)
print ("Расчётное значение длины цилиндра подвесного бака :%s"%e3)


Получим:

Расчётное значение площади подвесного бака :10.253
Расчётное значение радиуса подвесного бака :0.878
Расчётное значение высоты конуса подвесного бака :0.785
Расчётное значение длины цилиндра подвесного бака :0.393

При заданном объёме бака Vb=3, определим размеры для оптимальной компоновки из следующего листинга, когда условие для минимума Cx (2h=d или H=R) выполняются :

# -*- coding: utf8 -*-    
import numpy as np
from scipy.optimize import minimize
import matplotlib.pyplot as plt
def  objective(x):# целевая функция - площадь поверхности бака
         x1=x[0] # искомый радиус R цилиндра и основания конуса, высота которого H=R 
         x2=x[1]# искомая длина L цилиндра
         return 2*np.pi*x1**2+2*np.pi*x1*x2+np.pi*x1*(2*(x1**2))**0.5
def constraint(x): # ограничение на объём бака       
         return (2/3)*np.pi*(x[0]**3)+np.pi*x[1]*(x[0]**2)+(1/3)*x[0]*np.pi*(x[0]**2)-3
x0=[1,1]# начальные значения для поиска локального минимума
b=(0.0,1)# ограничение по не отрицательным значениям переменных
bnds=(b,b)
con={'type': 'ineq','fun':constraint}
res = minimize(objective, x0,bounds=bnds,constraints=con)
e=round(res['fun'],3)
e1=round(res['x'][0],3)
e2=round(res['x'][1],3)
print ("Расчётное значение площади подвесного бака :%s"%e)
print ("Расчётное значение радиуса подвесного бака :%s"%e1)
print ("Расчётное значение высоты конуса подвесного бака :%s"%e1)
print ("Расчётное значение длины цилиндра подвесного бака :%s"%e2)

Получим:

Расчётное значение площади подвесного бака :10.259
Расчётное значение радиуса подвесного бака :0.877
Расчётное значение высоты конуса подвесного бака :0.877
Расчётное значение длины цилиндра подвесного бака :0.363

Вывод:

В сравнении с вариантом, когда условие R=H не выполняется, общая площадь поверхности бака почти не изменилась. Этот вариант компоновки является оптимальным, что подтверждает и практика.

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

Измерение уровня топлива в подвесном топливном баке


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

В не сбрасываемом топливном баке измерение уровня топлива осуществляется датчиками, установленными в прямом канале, верхний открытый конец которого расположен над уровнем топлива, которое заполняет канал за счёт давления наддува Po.

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

Таким образом, уровень топлива в канале определяет уровень топлива в баке. Проблема в том, что свободная поверхность топлива не совпадает в канале и резервуаре. Ошибка измерения уровня топлива приводит к неэффективному расходу топлива.

Уровень топлива в баке изменяется согласно соотношения:

где: Ho – начальный уровень топлива в баке; V– скорость подачи топлива; t – время.

Для дальнейшего анализа зависимости скорости подачи топлива от времени воспользуемся соотношением, полученным в публикации [2]:

где: y – координаты свободной поверхности топлива в измерительном канале; L– коэффициент трения жидкости о стенки цилиндрического измерительного канала; R – радиус цилиндрического измерительного канала; g – ускорение свободного падения.

Начальные условия к дифференциальному уравнению (1) имеют вид:

y(0)=Ho, dy/dt=0.

Для численного решения дифференциального уравнения (1) средствами Python, введём следующие обозначения:

Изменение средней скорости топлива в измерительном канале.

# -*- coding: utf8 -*-    
import numpy as np
from scipy.integrate import odeint
import matplotlib.pyplot as plt 
R=0.0195
H=8.2
g=9.8
L=4.83*10**-2
V=0.039
def f(y,t):
         y1,y2=y
         return [y2,-g+(g*(H-V*t)/y1)+((L/(4*R))*y2**2)] 
t = np.arange(0,200,0.01)
y0=[H,0]
[y1,y2]=odeint(f,y0,t,full_output=False).T
plt.title("Изменение средней скорости топлива \n в измерительном канале")
plt.xlabel("t,s")
plt.ylabel("U,m/s ")
plt.plot(t,y2)
plt.grid(True)
plt.show()

Получим:

Уровни топлива в измерительном канале и в баке.

# -*- coding: utf8 -*-    
import numpy as np
from scipy.integrate import odeint
import matplotlib.pyplot as plt 
R=0.0195
H=8.2
g=9.8
L=4.83*10**-2
V=0.039
def f(y,t):
         y1,y2=y
         return [y2,-g+(g*(H-V*t)/y1)+((L/(4*R))*y2**2)] 
t = np.arange(0,10,0.01)
y0=[H,0]
[y1,y2]=odeint(f,y0,t,full_output=False).T
plt.title('Изменение уровня топлива ')  
plt.ylabel('H,m')
plt.ylabel('t,s')  
plt.plot(t,y1,"b",linewidth=2,label='Уровень топлива в измерительном канале')
y=H-V*t
plt.plot(t,y,"--r",linewidth=2,label='Уровень топлива в баке')
plt.grid(True)
plt.legend(loc='best')
plt.show()

Получим:

Ошибка измерения уровня топлива.

# -*- coding: utf8 -*-    
import numpy as np
from scipy.integrate import odeint
import matplotlib.pyplot as plt 
R=0.0195
H=8.2
g=9.8
L=4.83*10**-2
V=0.039
def f(y,t):
         y1,y2=y
         return [y2,-g+(g*(H-V*t)/y1)+((L/(4*R))*y2**2)] 
t = np.arange(0,200,0.01)
y0=[H,0]
[y1,y2]=odeint(f,y0,t,full_output=False).T
plt.title('Ошибка измерения уровня топлива ')  
plt.ylabel('d,m')
plt.xlabel('t,s')  
d=y1-(H-V*t)
plt.plot(t,d)
plt.grid(True)
plt.show()

Получим:

Вывод:

Приведенная математическая модель позволяет оценить погрешность измерения уровня топлива в баках самолётов.

Для ракеты нужно учитывать флуктуацию(колебания) жидкости в топливном баке ракеты. Такие флуктуации визуально показаны и в публикации [3].

Для учёта флуктуации топлива в баке, возможно рассмотрение и такой упрощённой модели:

Жидкость рассматривается как сосредоточенная убывающая масса с приведенным рассеиванием и жёсткостью. Но это тема уже другой статьи.

Выводы:

1. В статье на примере оптимизации формы подвесных топливных баков продемонстрированы возможности Python по численной оптимизации с несколькими ограничениями.
2. В статье на примере решения не классического дифференциального уравнения продемонстрированы возможности решения таких уравнений средствами Python.
3. Полученные решения могут использоваться и в учебных целях, не обременяя школу или Вуз покупкой Mathcad или других дорогостоящих пакетов.

Ссылки:

  1. Расчет коэффициента лобового сопротивления (Cx) простых тел и сравнение полученного результата с экспериментом.
  2. Измерение уровня жидкости в топливном баке ракеты.
  3. Незаметные сложности ракетной техники: Часть 4. Ещё про двигатели и баки.

Let's block ads! (Why?)