Кто разрабатывает 400GbE-коммутаторы для ЦОД

В конце 2018 года сразу несколько производителей оборудования для ЦОД представили коммутаторы 400G Ethernet (400GbE). Расскажем об анонсе нового железа подробнее.

/ фото Quinn Dombrowski CC BY-SA

Чем поможет 400GbE

По данным Cisco, в 2021 году 53% всех серверов будут сконцентрированы в гипермасштабируемых дата-центрах (hyperscale). Машинные залы этих ЦОД насчитывают сотни тысяч и даже миллионы машин. В таких условиях владельцам дата-центров важно справляться с постоянно растущим трафиком. Помочь с решением проблемы должен стандарт 400GbE.

Эта версия Ethernet имеет важное нововведение — кодирование PAM4. Оно использует для модуляции не два (как, например, NRZ), а четыре уровня сигнала. Такой подход удваивает пропускную способность сети. Увеличение числа уровней повышает вероятность возникновения искажений. Поэтому PAM4 требует внедрения методов коррекции ошибок с показателем BER (bit error rate) не выше 10⁻¹³ (для других Ethernet-стандартов это значение составляло 10⁻¹²).

Стандарт 400GbE разрабатывали в IEEE с 2014 года, а принят он был в конце 2017. По этой причине в 2018-м производители оборудования для дата-центров активно взялись за разработку новых решений.

Кто представил 400GbE-устройства

В конце октября прошлого года новую серию коммутаторов для обновлённого стандарта Ethernet представили в Cisco. Всего компания разработала четыре устройства: 3432D-S, 3408-S, 9316D-GX и 93600CD-GX.

Свитч Nexus 3432D-S имеет форм-фактор 1RU и 32 порта 400GbE. Что касается Nexus 3408-S, то это 4RU-шасси с портами 100 и 400GbE. Оба устройства этой линейки имеют коммутационную способность в 25,6 Тбита/с и буфер на 70 Мбайт.

Nexus 9316D-GX — это spine-свитч в форм-факторе 1RU с 16 портами 400GbE. Nexus 93600CD-GX представляет собой 1RU leaf-свитч с восемью 400-гигабитными портами. Устройства серии 9300-GX полностью совместимы с системой Cisco Application Centric Infrastructure (ACI). Она автоматизирует балансировку нагрузки и настройку виртуальных машин в ЦОД.

Кроме Cisco, свои 400GbE-решения в прошлом году анонсировали в Juniper. Компания планирует выпустить устройства для 400G Ethernet в первой половине 2019-го. Среди них будут две модели коммутаторов для дата-центров — QFX10003 и QFX5220. Каждая из них оборудована 32 портами для 400GbE.

Также Juniper разработала маршрутизатор для 400G Ethernet — модель PTX10003. Он доступен в двух вариантах: с пропускной способностью в 8 или 16 Тбит/с. Число 400GbE-портов в маршрутизаторах составит 16 и 32 соответственно. В PTX10003 будет встроена система шифрования по протоколу MACsec, который защитит от перехвата и подмены данные в сети.

Два коммутатора выпустила и компания Arista. Оба устройства оборудованы 32 портами, а их пропускная способность составляет 12,8 Тб/с.

Где будут внедрять 400GbE

Аналитики ожидают, что внедрять новые решения владельцы ЦОДов начнут уже в 2019–2020 годах. Технология 400GbE прежде всего рассчитана на крупных облачных провайдеров. Он поможет им справиться с ростом трафика в сетях. Ожидается, что спрос на публичное облако продолжит расти в ближайшем будущем примерно на 20% в год.

Также 400GbE поможет телекоммуникационным компаниям с внедрением 5G-сетей. Сети нового поколения приведут к увеличению мирового трафика в пять раз за ближайшие три года. Поэтому некоторые операторы уже сейчас тестируют 400GbE-коммутаторы. Например, в начале 2018 года на новые устройства перешли в Verizon.

Технология 400G Ethernet найдет применение и в сетях учебных и исследовательских заведений. Одноканальную 400-гигабитную сеть создали в Индианском университете США. Новая 400GbE-система поможет сотрудникам вуза быстрее переносить большие объемы данных (которые генерируют во время исследований) в облако и упростит обмен ими с коллегами из лабораторий.

/ фото Ernestas CC BY

Но о массовом переходе на новое оборудование говорить пока рано. По словам главного аналитика организации Doyle Research, в ближайшем будущем сети 400G Ethernet будут слишком дорогими. Их смогут себе позволить лишь владельцы гипермасштабируемых ЦОД вроде Facebook и Microsoft. К слову, эти ИТ-гиганты будут внедрять устройства от Arista.

Другая сложность, которая может замедлить внедрение 400GbE-устройств, — конкурирующие виды трансиверов для 400GbE: OSFP или QSFP-DD. OSFP-устройства потребляют меньше энергии по сравнению с QSFP-DD, но занимают больше места. Приёмопередатчики QSFP-DD не только меньше по размеру, но и совместимы с портами предыдущего поколения QSFP. Однако они потребляют больше электроэнергии, что приводит к росту счетов за электричество в дата-центрах. Пока неясно, какой из типов трансиверов приобретет большую популярность, поэтому есть риск разделения рынка на два лагеря.

В целом эксперты прогнозируют, что стандарт 400GbE начнет набирать обороты после 2020 года. Тогда цены на устройства будут снижаться, что сделает их внедрение целесообразным для большего числа компаний.

---

О чем мы пишем в корпоративном блоге:
Посты из Telegram-канала:

Let's block ads! (Why?)

[Перевод] Шесть историй, как код переписали с нуля

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

«Исходный код словно заржавел!» — Джоэл Спольски

Почти два десятилетия назад Джоэл Спольски устроил разнос Netscape за то, что она переписала кодовую базу браузера, в своём эпохальном эссе «Чего никогда нельзя делать». Он пришёл к выводу, что функционирующий софт абсолютно никогда не следует переписывать с нуля. У него было два основных аргумента:

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

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

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

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

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

---

Код браузера трижды переписывали с нуля

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

Netscape Navigator вышел в 1994 году, в первые годы коммерческого интернета. Не прошло двух лет — и компания открыла эпоху доткомов, проведя IPO на $3 млрд.

Первым серьёзным конкурентом Netscape стал Microsoft Internet Explorer, который вышел в 1996 году.

В начале 1998-го Netscape ещё оставался ведущим браузером, но с большим трудом. Netscape был коммерческой программой, которая продавалась за $49, а Microsoft раздавала IE бесплатно и поставляла как браузер по умолчанию в Windows.

После выхода Netscape 4.0 компания объявила, что следующая версия станет бесплатной и будет разработана сообществом open source, созданным и финансируемым компанией Mozilla. Для своего времени это был по сути беспрецедентный шаг, и Netscape приобрела много сторонников за такое смелое решение. Но в реальности это «сообщество» на самом деле так и не материализовалось. Джейми Завински, один из первых разработчиков браузера, объясняет:

Правда в том, что в состав участников проекта Mozilla входило около сотни штатных разработчиков Netscape и около тридцати внештатных, так что проект по-прежнему полностью принадлежал Netscape.

Команда пришла к выводу, что разработчики со стороны не заинтересовались проектом, в том числе по причине бардака в кодовой базе:

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

С чистого листа

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

Подготовка Netscape 6.0 заняла целых два года; и даже после всего этого было ясно, что браузер сырой. По словам обозревателя New York Times Дэвида Пога, браузер запускался целую минуту (!) и поглощал оперативную память. У него отсутствовал ряд простых функций юзабилити, которые были в предыдущих версиях:

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

Но это уже практически не имело значения, потому что за три года, что Netscape стоял на месте, Internet Explorer захватил всю оставшуюся долю рынка:

Когда началась переработка браузера, Netscape быстро уступила позиции Microsoft Internet Explorer. Новый браузер вышел три года спустя, он был глючным и медленным; а рыночная доля Netscape тем временем сократилась почти до нуля (график адаптирован из Википедии)

В 1999 году, когда полным ходом шла переделка браузера, корпорация AOL приобрела Netscape за $10 млрд. Всего через два года после выхода Netscape 6.0 подразделение Netscape в AOL было ликвидировано.

Mozilla, сообщество с открытым исходным кодом, созданное Netscape, продолжит существование и выпустит браузер Firefox в 2002 году — ещё один проект с чистого листа. Firefox удалось вернуть часть пользователей, которые ушли к Microsoft.

Но Netscape как бизнес умер (Microsoft закопает останки интеллектуальной собственности Netscape в результате сделки с AOL в 2012 году).

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

Выводы

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

Но всем нам пришлось пережить годы застоя в веб-технологиях под бесконечной, удушающей монополией IE6, пока мы с нетерпением ждали новый браузер, который вдохнул жизнь в индустрию. И конец эпохи IE6 положил не Firefox, а Google Chrome.

В любом случае, речь не о том, как сказался проект на интернете. Речь о том, каков результат для компании. Смерть Netscape нельзя полностью списать на эти причины: суд согласился, что Microsoft намеренно злоупотребила своей монополией. Но конечно, решение переписать всё с нуля стало важным фактором и привело к конечному результату: разрушению компании стоимостью в миллиарды долларов и тысячам увольнений. Поэтому я соглашусь с Джоэлом, что чистые последствия этого решения оказались катастрофическими.

---

В начале 2000-х годов чикагская студия веб-дизайна под названием 37signals стала известной благодаря влиятельному и часто противоречивому блогу, который вели основатели Джейсон Фрид и DHH.

Когда я только начинал заниматься веб-дизайном, они привлекли моё внимание серией статей с примерами неправильного дизайна и вариантами, как их переделать, для таких сайтов, как Google и PayPal. Проект назывался 37better.

Редизайн 37signals формы доставки FedEx (вверху) по-прежнему лучше реального дизайна, почти два десятилетия спустя

У компании была система управления проектами для внутреннего использования, которую они в 2004 году выпустили в качестве SaaS-сервиса под названием Basecamp.

В то время SaaS был ещё новинкой. Инструменты управления проектами продавались в коробках с четырёхзначными ценниками и увесистыми руководствами. Все они работали на концепции моделирования критических путей и рисовали сложные диаграммы Ганта. Basecamp продавался за $50 в месяц и стал глотком свежего воздуха со своим суперпростым интерфейсом и ориентацией на коммуникации.

Перенесёмся на несколько лет вперед, У Basecamp полмиллиона счастливых пользователей, платежи поступают каждый месяц, но Джейсон и Дэвид начали беспокоиться.

Несколько лет назад Дэвид рассказал эту историю на конференции Business of Software. Он признался, что находился под влиянием Джоэла Спольски и верил, что переписывание программного обеспечения убьёт компанию. Кроме того, был некий элемент самодовольства и уверенности в собственной правоте в связи с популярностью движения Agile:

[Меня] полностью поглотила идея трансцендентного ПО… Бесконечно пластичный код. Бесконечно ценное легаси. Вы можете изменить что угодно, переписать любую программу, любой код… Если программное обеспечение трудно изменить, сам виноват. Ты плохой программист, значит, нужно совершенствоваться.

Однако после «семи жирных лет» компания оказалась в затруднительном положении — и проблема не имела ничего общего с техническим долгом.

Золотые наручники

Всё началось с того, что ребята заметили в себе недостаток энтузиазма. Мало того, что не хватало мотивации работать над флагманским продуктом, так они и сами особо не пользовались своей программой.

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

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

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

Часть проблемы в том, что вы постоянно слушаете нынешних клиентов, но не слышите будущих:

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

Разработчики стали рассматривать прибыльный продукт как пару золотых наручников:

Главное убедиться, что все нынешние пользователи довольны. Деньги приходят каждый месяц, новый чек, новый чек, новый чек. Отлично. Но тогда вытяните руки и признайте: «Всё, я больше никогда не изменю свое программное обеспечение».

Спойлер: Basecamp переписали с нуля, и получилось здорово. Это заняло около года, и сразу после выпуска Basecamp 2 количество новых регистраций удвоилось.

Мне кажется, они сделали две главные вещи.

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

Неужели мы настолько самонадеянны, чтобы считать идеи 2003 года по-прежнему самыми лучшими идеями в 2011 году? Да, меня обвиняли в высокомерии, но весь пар вышел в 2008 году.

Таким образом, они представили Basecamp 2 как совершенно новый продукт, без каких-либо гарантий обратной совместим с Basecamp Classic. Появилось много нового, что-то вообще исчезло, а многое совершенно изменилось.

Это решение дало определённую степень свободы. Свобода мотивирует, а мотивированные люди лучше работают.

Помогло и отсутствие необходимости поддерживать каждый из вариантов использования оригинального продукта. Например, оригинальный Basecamp позволял размещать документы на собственном FTP-сервере. Разработчики удалили эту и другие подобные функции, которые раньше имели смысл, а сейчас стали маргинальными. Такое урезание ненужного функционала позволило вывести новый продукт на рынок в разумные сроки.

Закат считается вредным

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

Дэвид знатно проехался по термину «закат программного обеспечения»:

Кто-то где-то придумал прекрасный эвфемизм под названием «закат»… Назвать уничтожение программного обеспечения «закатом»… Типа все пользователи лежат на пляже — и с умилением наблюдают, как их информация исчезает. Это прекрасно!

Единственные люди, которые верят в «закат» — те, кто его так называет. Ни один пользователь, который действительно когда-либо проходил через период заката, не возвращается и не говорит: «О, это было красиво». Они возвращаются и говорят: «Чёрт! Я вложил сюда годы работы!.. И теперь ты собираешься меня закатить?!»

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

Действительно ли мне нужен Basecamp? Если всё равно придётся переносить всё барахло, может, перенести его куда-нибудь ещё. Если нужно паковать вещи в коробки и загружать в грузовик, я могу просто отправить этот грузовик через весь город. Не такая уж большая проблема. Большая проблема — это упаковать все манатки. А уж куда переезжать, опять в Basecamp или в другое место, это уже второстепенный вопрос.

Дэвид сравнил Basecamp Classic с Leica M3: камера не производилась с 1967 года, но Leica обещает поддерживать и ремонтировать её до конца своих дней (фото: Dnalor 01)

Вместо этого Basecamp обязался «уважать своё наследие»: они упростили обновление на новую версию, но не требовали покидать Basecamp Classic. Кроме того, они обязались поддерживать Basecamp Classic вечно.

Прикол в том, что спустя четыре года они сделали это снова: в 2015 году вышел Basecamp 3, опять переписанный с нуля, с некоторыми новыми функциями и без некоторых старых, и опять многое изменилось. Как и раньше, пользователи более старых версий могут легко сделать апгрейд. Но если хотят, могут продолжать использовать Basecamp Classic или Basecamp 2 «до конца интернета».

Basecamp 3 не собирается ничего «закатывать». Не текущую версию, не классическую, оригинальную версию Basecamp. Какая-то из них хорошо работает для вас? Круто! Пожалуйста, продолжайте использовать её до конца интернета! Мы позаботимся о том, чтобы программы оставались быстрыми, безопасными и всегда доступными.

Но возникает много «но». Разве это не дорого? Поддержка нескольких версий требует много усилий? Что насчёт безопасности? Как насчёт устаревших кодовых баз? Что тут можно сказать. Мы просто заботимся о клиентах, даже если они не желают обновляться по нашему графику.

Выводы

Лично мне такая модель кажется действительно вдохновляющей.

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

Конечно, поддержка нескольких версий бесконечно долгое время имеет свою цену; но, как говорит Дэвид:

Это не бесплатно. Конечно, нет. Это ценный продукт и конечно, поддержка не обходится бесплатно. Но она того стоит.

---

Примечание: значок хипстера

Microsoft сделала VS Code, чтобы достучаться до разработчиков на других платформах.

Вы должны помнить, что долгое время Microsoft предлагала «всё или ничего». Если вы использовали Visual Studio, то обязательно работали в .NET, и наоборот. Это разделило сообщество программного обеспечения на два больших, в основном взаимоисключающих лагеря — в ущерб всем.

Обращение к крутым ребятам

Ситуация стала меняться ещё в годы Стива Балмера: вспомните, насколько громким стало решение разработчиков ASP.NET не изобретать jQuery!

Одной из главных задач генерального директора Сатьи Наделлы стало обращение к разработчикам за пределами своего «огороженного сада».

Но была проблема. Вот что говорит Джулия Льюсон, вице-президент Visual Studio в этом выпуске подкаста The Changelog:

Мы ничего не могли предложить целому классу разработчиков: современным, веб-ориентированным, которые работают с Node и JavaScript — нам просто не о чем было с ними говорить. Этих разработчиков мы просто ничем не могли привлечь.

Таким образом, VS Code создавался, чтобы сломать этот барьер и сказать: «На самом деле знаете что, парни? У нас всё-таки есть кое-что полезное для вас».

Visual Studio — тяжеловесный продукт во всех смыслах: только установка может занять более получаса. Он поддерживает широкий спектр сложных вариантов использования, на которые полагаются корпоративные клиенты. Таким образом, не было смысла брать Visual Studio за отправную точку и добавлять функции в новом проекте на других платформах. И очевидно, что идея выпуска Visual Studio для Mac или Linux не особо поддерживалась.

Поэтому Microsoft начала с нуля, без гарантий обратной совместимости.

На самом деле, не совсем с нуля: у Microsoft уже были некоторые важные части, такие как редактор Monaco в браузере. И поскольку VS Code представляет собой приложение Node.js (написанное на Typescript и запущенное в Electron), то они воспользовались богатыми ресурсами экосистемы JavaScript.

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

VS Code стал основным редактором для JS-хипстеров (диаграмма из отчёта State of JavaScript Survey, 2018)

Оба продукта по-прежнему активно разрабатываются, и нет никаких признаков того, что Microsoft намерена закрыть Visual Studio.

Выводы

В отличие от Netscape, компании Microsoft действительно удалось создать вокруг VS Code активное open source сообщество. Оно приумножило усилия разработчиков по улучшению продукта.

Из всех проектов с открытым исходным кодом, Visual Studio Code занимает 13-е место по количеству звезд на GitHub — по совпадению, чуть ниже Linux!

Конечно, не каждая компания может позволить выкладывать свой основной продукт в свободный доступ. Но если open source является частью вашей стратегии развития, есть смысл сравнить истории Microsoft и Netscape — и выяснить, что Microsoft сделала иначе, чтобы её сообщество процветало.

Ещё один важный фактор: Microsoft снабдила VS Code качественной моделью расширяемости, в результате чего сообщество уже написало около 10 000 расширений.

Один из последних выводов из истории VS Code в том, что за последние несколько лет всё кардинально изменилось: в наши дни как никогда просто создавать прототипы и программное обеспечение.

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

---

Примечание: значок заката

Inbox for Gmail первоначально представили как альтернативный минималистичный UX для Gmail, «с фокусом на том, что действительно имеет значение». Он никогда не пытался соответствовать по функциональности оригинальному Gmail, а также представил новые функции: тематические группы (bundles), закреплённые письма и отложенные сообщения.

Некоторые пользователи, включая меня, с энтузиазмом приняли Inbox. Я всегда думал, что Inbox — демонстрационная версия того, чем в конечном итоге станет Gmail, поэтому мирился с отсутствием некоторых нюансов Gmail, ожидая, что они в конечном итоге доберутся до Inbox.

Два интерфейса, один сервис

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

Однако через некоторое время Inbox перестал улучшаться — стало ясно, что Google больше не вкладывает в него ресурсов. Естественно, через четыре года после запуска Google объявила о закате Inbox.

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

Но не всё из Inbox перенесли в Gmail: например, люди настолько привыкли к «режиму паузы» (snoozing), что без него сейчас буквально физически страдают.

Выводы

Inbox дал возможность разработчикам Gmail экспериментировать с функциями, не нарушая рабочий процесс подавляющего большинства пользователей.

Однако обслуживая обе версии на одном бэкенде, Gmail поставил жёсткие ограничения на инновации.

Ещё раз, Google много критиковали за закрытие популярного сервиса. Конечно, Google постоянно закрываетсвои проекты, так что ничего неожиданного.

Но в этом случае первоначальное отношение Google к Inbox заставило поверить, что перед нами демонстрационная версия будущего Gmail. Как сказал бы DHH, закат вышел некрасивый: многим людям оказалось неприятно вернуться к старому продукту и потерять инновационные рабочие процессы Inbox.

Думаю, для многих переход дался бы гораздо проще, если бы перед закрытием Inbox все его функции интегрировали в Gmail.

---

Примечание: значки печального упадка и «деньги, деньги, деньги»

FogBugz — особенно интересный случай, поскольку это продукт самого Джоэла Спольски: он даёт представление о том, как принцип «никогда не переписывать» сталкивается с реальной жизнью.

До появления Jira и GitHub Issues существовала веб-система для отслеживания тикетов под названием FogBugz. Выпущенная в 2000 году, эта система стала первым продуктом новой компании Fog Creek Software, которую Джоэл основал с Майклом Прайором. И более десяти лет FogBugz оставался их флагманским продуктом. Изначально он продавался только как коробочная версия для установки на свои собственные серверы, но позже вышел вариант SaaS с оплатой по подписке.

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

FogBugz первоначально написали на классическом ASP, который работал на серверах Windows. Когда вышел ASP.NET, Джоэл объяснил, почему не спешит обновляться.

Чтобы установить FogBugz на серверах Linux, стажёр компании написал компилятор Thistle для преобразования классического ASP в PHP. К 2006 году Thistle вырос в проприетарный язык программирования под названием Wasabi, который компилируется в ASP, PHP и клиентский JavaScript.

Странная история Wasabi

В наше время разработка собственного, проприетарного языка программирования и компилятора — это, скажем так, эксцентричный выбор. Так что интересно посмотреть, как всё происходило.

В какой-то момент Джоэл упомянул Wasabi в одном из сообщений в блоге. Некоторые подумали, что это шутка, поэтому он пояснил, что не шутка. У коллеги-блогера Джеффа Этвуда взорвалась голова от этой новости:

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

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

Размышляя над Wasabi в содержательном эссе под названием «Технический долг и поиск ветра», бывший инженер Fog Creek Тед Унангст сравнивает процесс с путешествием без карты:

Представьте, что вы находитесь в Саванне, штат Джорджия, и хотите поехать в Лондон, Англия. У вас нет карты, только смутное чувство направления… Вы не пойти по прямой, потому что у вас нет лодки, а перед вами океан. Но зато приятный пляж ведёт на северо-восток, а это примерно подходящее направление. Вы идёте по пляжу, идёте и идёте. Проходит время. Вы смотрите и видите, что с каждым шагом всё ближе к цели, хотя не двигаетесь к ней напрямик.

Где-то в Бостоне, или в Новой Шотландии вы наконец останавливаетесь и думаете о своём выборе. Может эта дорога не ведёт в Лондон? Далеко на галёрке слышен смех: «Ха-ха-ха, посмотри на этих дебилов. Не видят разницы между Англией и Новой Англией. Дайте этим дуракам карту». Но именно в этом проблема: у тебя нет карты. Карты делают люди, которые почти по определению не знают, куда идут.

В любом случае, объясняет Джейкоб Кралл, ещё один бывший разработчик Fog Creek, то решение принесло в жертву завтрашнюю ремонтопригодность ради сегодняшней скорости разработки. И к 2010 году стали приходит счета по этому долгу.

Мы не выложили [Wasabi] в open source, поэтому несли затраты в одиночку, за счёт своих основных прибыльных продуктов… Это была огромная зависимость, которая требовала наличия постоянного разработчика на одном этом продукте: недёшево для компании нашего размера. Иногда компилятор ругался на кусок кода, который выглядел вполне разумно для человека. Он медленно компилировал. Visual Studio не мог легко редактировать или подключить отладчик к FogBugz… Всех новых сотрудников сначала долго обучали Wasabi, независимо от их предыдущего опыта… Кроме того, мы жили не в вакууме. Языки программирования, конечно, улучшались за пределами Fog Creek… Разработчики начали чувствовать, что их блестящие идеи сталкиваются с ограничениями нашей маленькой вселенной Wasabi.

Точка перегиба

К тому времени FogBugz исполнилось уже десять лет: это был зрелый и стабильный продукт. В качестве побочного проекта Джоэл запустил Stack Overflow совместно с Джеффом Этвудом (очевидно, взорванная голова Джеффа к тому времени успела зажить).

FogBugz постепенно старел. Хотя рынок баг-трекеров оставался фрагментированным, на первый план стала выходить Jira от Atlassian, которая вышла через пару лет после FogBugz. Она стала выбором по умолчанию, особенно для крупных корпоративных пользователей.

На эту конкретную точку перегиба в истории FogBugz действительно интересно посмотреть со стороны. Как и у Basecamp, у них был прибыльный, зрелый продукт. Да, уже не такой модный и может над ним было не очень интересно работать. Хорошо это или плохо, но он вобрал в себя многие годы технологических изменений и новые идеи о том, как решать одну конкретную проблему: трекинг багов.

Конечно, был вариант Basecamp: с учётом всего опыта взять и переписать FogBugz с чистого листа. Предполагаю, эта идея не зашла слишком далеко, ведь мы помним: «чего никогда нельзя делать», «худшая стратегическая ошибка» и так далее, и тому подобное.

Недавно мне попалась на глаза статья 2009 года, которую Джоэл написал для Inc. Magazine. Его авторская колонка под заголовком «Означает ли медленный рост медленную смерть?» по тону совершенно не похожа на обычную самоуверенную напыщенность: она звучит интроспективно, неуверенно, наполнена сомнениями. Джоэл беспокоится о быстром росте Atlassian, рассуждает, есть ли на рынке место для нескольких игроков.

Мне пришлось задуматься. У нас появился большой конкурент, который растёт намного быстрее нас. Компания закрывает большие сделки с крупными, корпоративными клиентами… Между тем, наш продукт намного лучше, и мы хорошо управляемая компания, но это, кажется, не имеет значения. Почему?

Он решает сделать две вещи. Во-первых, добавить все функции в FogBugz:

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

Во-вторых, создать корпоративный отдел продаж. Джоэл признаётся, что здесь он не силён, и находит неприятной данную задачу.

Не знаю, как сработали эти меры. Последний раз Джоэл упоминал FogBugz в своём блоге в мае 2010 года, вкратце анонсировав новую версию.

Новая надежда

А произошло вот что:

В районе десятилетнего юбилея Fog Creek Software я начал думать: чтобы сохранить мотивацию наших сотрудников ещё на десять лет, нужно начать работу над чем-то новым.

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

Джоэл представил эту программу как инструмент управления на более высоком уровне, чем FogBugz:

Честно говоря, со всем этим причудливым программным обеспечением для «управления проектами», я никогда не мог нормально отследить, кто над чем работает… Будучи основателем двух компаний, я шёл по коридорам и видел десятки людей, которым платят за то, чтобы сидеть за компьютерами… и я понятия не имел, правильно ли они выполняют свою работу или они считают важным то, что на самом деле может и неважно.

При создании Trello разработчики Fog Creek получили шанс использовать современные технологии:

Мы используем передовые технологии, поэтому не обходится без жертв. Раны наших разработчиков разбросаны по всему MongoDB, WebSockets, CoffeeScript и Node. Но зато теперь им интересно. На сегодняшнем напряжённом рынке труда талантливые программисты во многом решают, над чем хотят работать. Если вы дадите им интересный продукт… им понравится и они будут любить свою компанию.

Trello с самого начала поддерживал плагины, так что сторонние разработчики начали помогать:

У плагинов и API наивысший приоритет… Никогда не делайте самостоятельно продукт, если можете предоставить базовый API, и ценные пользователи… сделают его для вас. Для команды Trello действует правило, что если какая-то функция может быть реализована через плагин, то она должна быть реализована именно таким образом.

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

В то время как FogBugz был вертикальным продуктом — ориентированным на определённую рыночную нишу — Trello являлся горизонтальным продуктом, подходящим для чего угодно. Джоэл считает правильным «горизонтальное движение» Fog Creek на том этапе:

Практически невозможно создать крупный горизонтальный продукт, полезный во всех сферах. Он не может быть дорогим, потому что вы конкурируете с другими горизонтальными продуктами, которые могут амортизировать свои затраты на разработку для огромного количества пользователей. Это высокий риск и высокая награда: такой путь не подходит для молодого стартапа, но хорошая идея для второго или третьего продукта от зрелой и стабильной компании, такой как Fog Creek.

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

В 2014 году Trello выделили в независимую компанию. Три года спустя её с более чем 17 миллионами пользователей продали за $425 млн. По иронии судьбы, покупателем стал Atlassian, старый заклятый враг Fog Creek.

Тем временем возвращаемся домой…

Fog Creek продолжила разработку ещё одного нового продукта, среды совместного программирования под названием HyperDev, которую позже переименовали в GoMix, а затем в Glitch.

В то же время система FogBugz прозябала в безвестности. В 2017 году кто-то решил, что FogBugz — вообще глупое название, и инженерные усилия пошли на ребрендинг продукта как Manuscript. Год спустя — всего несколько месяцев назад — Fog Creek продала продукт небольшой компании DevFactory, которая немедленно вернула название FogBugz.

Под руководством генерального директора Анила Дэша Fog Creek стала компанией с одним продуктом и сменила название на Glitch.

Выводы

У меня много мыслей по этому поводу.

Ключ к пониманию истории заключается в том, что Fog Creek всегда заботилась не столько о баг-трекинге, сколько о расширении возможностей программистов — начиная со своих собственных:

Главная задача: создать комфортные условия для работы. Мы сделали сотрудникам личные кабинеты, они летали только первым классом, работали 40 часов в неделю, получали бесплатный обед, кресла Aeron и лучшие компьютеры. Мы поделились нашей гениальной формулой с миром: отличные условия работы → отличные программисты → отличное программное обеспечение → прибыль!

С учётом этой «формулу» можно сделать логичный и ободряющий вывод: Fog Creek построил бизнес вокруг счастья разработчиков. Это отразилось как на продуктах компании, так и на её внутренней «операционной системе». Первый продукт, баг-трекер, послужил основой для запуска нового продукта, который решил аналогичную проблему более абстрактным способом.

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

Впрочем, немного грустно, как всё закончилось для FogBugz. Не думаю, что разработчики Fog Creek были особо счастливы в последние дни перед продажей.

Ясно, что были проекты поважнее и покрупнее: Stack Overflow, Trello и Glitch — каждый в отдельности гораздо полезнее и ценнее, чем FogBugz; и одному человеку невозможно уследить за всем. Поэтому я не могу никого винить, в частности, за потерю интереса к FogBugz с 20-летней кодовой базой и сильной конкуренцией на рынке. Но лояльные пользователи хотя бы нашли хороший дом и не получили лекарство типа «закат»!

Однако сентиментальная часть меня предпочла бы более достойно «почтить наследие» всех причастных к созданию и использованию этого продукта за минувшие годы.

---

Примечание: значок «тайная операция»

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

Остановите меня, если слышали это раньше

В начале 2000-х у Майка МакДермента была маленькая дизайнерская фирма. Он решил, что бухгалтерский софт слишком сложный, поэтому для выставления счетов использовал Word и Excel.

Всё нормально работало до одного случая:

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

Майк дизайнер, а не программист, но ему и двум соучредителям удалось собрать инструмент, достаточно хороший, чтобы несколько человек платили за его использование по $10 в месяц. Потребовалось почти четыре года, чтобы бизнес вышел из подвала родительского дома.

К 10-летнему юбилею программы (звучит знакомо?) Freshbooks стала прибыльной фирмой с более чем 10 миллионами пользователей и 300 сотрудниками.

Но имелась одна проблема. Ко времени, когда компании удалось нанять «настоящих» программистов, у них был миллион строк «кода основателя». Внешний аналитик рассмотрел кодовую базу и пришёл к выводу:

«Хорошая новость в том, что вы решили самую трудную задачу. Вы выяснили, как построить бизнес, и у вас есть продукт, который нравится людям. Плохая новость в том, что вы, ребята, плохо разбираетесь в технологиях».

Что более важно, в существующем продукте невозможно было реализовать имеющиеся идеи:

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

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

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

Таким образом, они предприняли несколько попыток очистить беспорядок, не переписывая систему с нуля; но «заменить шины на ходу» оказалось невозможно.

Что произошло дальше, может вас удивить

МакДермента посетила идея втайне создать «конкурента» FreshBooks.

Он основал в Делавэре совершенно новую компанию под названием BillSpring. У неё был свой сайт, бренд и логотип. Стараясь не связывать две компании, он поручил внешнему юристу разработать для неё новые документы.

Команда разработчиков внедрила гибкие практики разработки по книге Джеффа Готельфа и Джоша Сейдена «Lean UX: проектирование отличных продуктов с гибкими командами»: скрам-команды и еженедельные итерации с обратной связью от реальных клиентов. МакДермент попросил их вести себя как стартап, а его воспринимать как венчурного инвестора:

«У вас четыре с половиной месяца. Если выйдете на рынок, получите больше денег. В противном случае конец».

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

По окончании первого года BillSpring стала взимать плату. В какой-то момент новый продукт получил неожиданную оценку качества:

«Один человек позвонил, чтобы отменить подписку на FreshBooks и перейти в нашу новую компанию, — говорит МакДермент. — Это был отличный день».

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

Постепенно клиентов «классического» FreshBooks допустили к новой версии, но они всегда могли вернуться к старой, если захотели.

Выводы

Тайный проект FreshBooks обошёлся недёшево: по оценке МакДермента, они потратили на него $7 млн. Впрочем, после более чем десятилетнего роста исключительно на собственных ресурсах они привлекли $30 млн венчурного капитала, так что деньги имелись. Не все могут такое себе позволить.

Forbes оценивал выручку FreshBooks в 2013 году в $20 млн. После завершения обновления в 2017 году они заработали $50 млн. Неизвестно, сколько пришло от нового продукта, однако написание системы с нуля явно не замедлило рост компании.

МакДермент говорит, что процесс разработки и внедрения новых функций стал быстрее и проще. Ещё важнее, что теперь в их руках появился продукт, в котором реализованы лучшие идеи. С таким не страшно смотреть в будущее.

Кроме того, полученный опыт изменил культуру компании — в хорошем ключе. Когда они притворялись стартапом, то научились работать как стартап. Практики Lean UX распространились на всю команду разработчиков. Клиенты принимают активное участие в разработке новых функций.

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

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

---

Некоторые мысли

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

Но совет предполагает, что в итоге мы получим оригинальный продукт плюс набор новых функций.

Но что делать, если вы хотите удалить функциональность? Или реализовать какую-то опцию совершенно иначе? Что делать, если с опытом пришли идеи принципиально нового подхода?

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

Когда возникают мысли переписать всё с нуля, может, стоит задать другие вопросы. Может, создать собственного конкурента? Если мой продукт FogBugz, то что будет моим Trello? Если это Visual Studio, как будет выглядеть мой VS Code?

Если сравнить статью Спольски о Netscape и пост DHH про Basecamp, то они согласны в одном: у легаси есть ценность.

Хорошая новость в том, что вам не нужно выбрасывать эту ценность, чтобы внедрять инновации.

Let's block ads! (Why?)

Механизированные руки и манипуляторы — рассказываем, чем занимается лаборатория робототехники Университета ИТМО

В Университете ИТМО на базе кафедры систем управления и информатики (СУиИ) открыта лаборатория робототехники. Расскажем о проектах, над которыми трудятся в её стенах, и покажем инструментарий: промышленных роботов-манипуляторов, робототехнические захватные устройства, а также установку для проведения испытаний систем динамического позиционирования с использованием роботизированной модели надводного судна.

Специализация

Лаборатория робототехники относится к старейшей кафедре Университета ИТМО, которая называется «Системы управления и информатика». Она появилась в 1945 году. Сама лаборатория была запущена в 1955 году — тогда в ней занимались вопросами автоматизации измерений и расчетами параметров надводных судов. Позже спектр направлений был расширен: добавили кибернетику, САПР, а также робототехнику.

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

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

Проекты

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

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

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

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

Кроме того, в парке роботов лаборатории имеется исследовательская установка KUKA youBot, представляющая из себя пятизвенный робот-манипулятор, закрепленный на мобильной платформе со всенаправленными колесами.

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

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

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

Другим примером робототехнической установки в лаборатории является ячейка FESTO Robot Vision Cell. Этот комплекс используется для имитации технологических операций на производстве, например сварки. Для реализации такого сценария ставится задача планирования движения: имитационный сварочный инструмент обходит по контуру металлической детали.

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

Проект, выполненный на базе робототехнической ячейки FESTO Robot Vision Cell с промышленным роботом Mitsubishi RV-3SDB, решает задачи планирования движений.

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

На практике полученное решение можно применить для нанесения гравировки или рисования.

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

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

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

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

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

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

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

Работа с партнерами и планы

Один из наших партнеров — британская компания TRA Robotics. Вместе мы работаем над совершенствованием алгоритмов управления промышленными роботами для предприятия цифрового производства. На таком предприятии весь производственный цикл: от разработки до изготовления промышленной продукции, будут выполнять роботы и системы ИИ.

Среди других партнеров — концерн «Электроприбор», совместно с которым мы разрабатываем мехатронные и робототехнические системы. Наши студенты помогают сотрудникам концерна в области приборостроения, разработки программного обеспечения и производственных задач.

Еще мы сотрудничаем с General Motors, развиваем робототехнику вместе с InfoWatch. Также сотрудники лаборатории плотно взаимодействуют с компанией АО «Навис», которая реализует проекты по разработке систем динамического позиционирования для надводных судов.

На базе Университета ИТМО работает Лаборатория молодежной робототехники, где школьники готовятся к состязаниям мирового уровня. К примеру, в 2017 году наша сборная выиграла World Robot Olympiad в Коста-Рике, а летом 2018 наши воспитанники взяли два призовых места на Всероссийской олимпиаде школьников.

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

Фотоэкскурсии по другим лабораториям Университета ИТМО:

Let's block ads! (Why?)

НАСА предупреждает SpaceX и Boeing о недоработках в космических кораблях

Космический корабль Crew Dragon (Источник: ТАСС)

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

Агентство имеет полное право выносит предупреждения своим партнерам, поскольку обе компании работают с НАСА по контракту. SpaceX ранее получила $2,6 млрд, а Boeing — $4,2 млрд. Обе компании обязались разработать ракету и капсулу для того, чтобы США вновь получили возможность запускать астронавтов на МКС своими силами. Последний раз это было сделано в 2011 году.
Каждый год агентство инспектирует ход выполнения программ партнерами, этот и прошлый год не является исключением. В ходе инспекции агентство выявило проблемы у капсулы Boeing — она подвержена влиянию внешних факторов выше нормы после того, как приводится в действие тепловая защита.

Для SpaceX проблема состоит в уязвимости баков ракеты (в НАСА не забыли о взрыве, произошедшем в 2016 году), а также в процессе заправки ракеты «на ходу», в момент нахождения астронавтов на своем «рабочем» месте. Обычно ракеты заправляются без людей, поскольку существует ненулевая угроза взрыва во время процесса заправки топливом. Но в SpaceX решили по-другому, частично для ускорения процесса, чтобы охлажденное топливо не слишком нагревалось в процессе подготовки ракеты к запуску.

Кроме того, у НАСА есть замечания к парашютной системе капсул обеих компаний, как SpaceX, так и Boeing. «Выявлены серьезные проблемы, которые могут повлиять на выполнение рабочего плана как у SpaceX, так и у Boeing», — говорится в отчете.

По словам источников Reuters у НАСА гораздо больше замечаний, чем отмечено в отчете. К каждой из компаний-партнеров агентство сформулировало около трех десятков замечаний. К сожалению, о том, что это за проблемы, неизвестно — ни НАСА, ни партнеры агентства пока что не комментировали ситуацию. Тем не менее специалисты заявляют, что обе компании должны решить все проблемы до момента запуска астронавтов (и космотуристов) в околоземное космическое пространство.

Корабли, о которых говорится в отчете — CST-100 StarLiner (корабль Boeing) и Crew Dragon (корабль SpaceX). На второе марта был запланирован первый беспилотный запуск Crew Dragon, причем он должен был состояться еще раньше, но его постоянно переносили из-за разных проблем. Полетные испытания CST-100 StarLiner тоже изменили, график сдвинули с марта на апрель. Пилотируемые запуски SpaceX должна была начать осуществлять с июля этого года, Boeing — с августа. Кроме самих кораблей, партнеры НАСА разрабатывают и скафандры для команды. Не так давно компания Boeing представила свою разработку, которая получила название «Boeing Blue».

По условиям контракта с НАСА, космические корабли должны вмещать экипаж в составе не менее четырех человек. Также в отсеках, по требованиям НАСА, должна быть возможность разместить и 100 кг полезного груза. Аппарат должен иметь возможность оставаться пристыкованным к станции в течение 210 дней для того, чтобы обеспечить доставку астронавтов и космонавтов на Землю, а в случае необходимости выполнить экстренную эвакуацию команды. НАСА считает, что работа с новыми кораблями Boeing и SpaceX позволит увеличить экипаж станции вплоть до семи человек. Благодаря этому увеличится и количество времени, которые можно уделить научным исследованиям.

Представитель Boeing выступил с заявлением о том, что компания «закрыла» риск уязвимости капсулы корабля, таким образом, программа испытаний, проведенная в январе, выполнена успешно. По мнению экспертов этой компании, корабль Boeing и все его элементы не только соответствуют требованиям безопасности НАСА, но даже превосходят их.

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

Let's block ads! (Why?)

Meet A Content Strategist: An Interview with Dmitry Kabanov, Techstars Startup Digest curator and SXSW Advisor

Dmitry learned the language of business but I think about the world as an engineer. He works with tech brands to create content and promote corporate culture at scale. Apart from it, he is one of the veterans at Techstars Startup Digest, and he is acting as an advisor for the SXSW tech festival.

Here is his interview with the LAMA app platform.

^{Photo by GLPH.Media (in Russian) circa 2011}

LAMA: You have an academic background in engineering. How did you make the jump to working with content? Does your training help you approach your work from a fresh perspective?

dmitrykabanov: Back in 2010, my research supervisor recommended «Getting Real», the book by Jason Fried and David Hansson. After that, he invited me to join his SEO and digital marketing agency startup. I didn’t like the SEO part of the job, so I decided to focus on building my own expertise in the content creation business. My engineering background helps me to be on the same footing as the founders of startups and bigger tech firms that want to storytell and promote their products.

This is instrumental to building off of user generated content. As a matter of fact, I myself still use podcasting as my networking vehicle. Back in the day, it allowed me to meet tons of tech leaders without having a bio or name in the industry and get first clients for my content marketing agency.

LAMA: What would be your best advice for a firm thinking of starting their own podcast? What makes a great piece of marketing content in 2018?

dmitrykabanov: I believe that this comeback will be really big for podcasting. And, to win in this wave of new audio shows starting this year or next year, businesses should focus on one strategic pillar and one tactical pillar. First, the strategic one is about projecting their brand values, not products, to the interests of their audiences. This will help them find guest speakers and topics that relate to their brands and be on point with questions that their listeners are looking for answers to.

Second, the tactical one is about making more than just audio out of the podcasting process. It’s about redistribution of audio in text transcripts and blog posts. Plus, documenting the process behind the show, filming it, and sharing those short videos in a company’s social media profiles.

LAMA: How would it differ from content that made the grade 5-6 years ago, when you started your content creation business?

dmitrykabanov: What’s really different today is that there’s no point in podcasting once a month. The pace and the volume of content that goes out in today’s web has grown so much that in order to be noticed by an average listener, you have to be both patient and resourceful to produce content on a regular basis: biweekly, once a week, or even daily. That’s quite an issue for tech companies that are sometimes struggling to put all the pieces together and set up their branded shows.

LAMA: You run the Techstars Startup Digest for Moscow. What are the most prevalent local trends you’ve picked up on?

dmitrykabanov: I’ve been curating Moscow’s Techstars Startup Digest for seven years, and it’s been a super-fruitful experience for me as a local curator. Apart from publishing my weekly digests and networking, I have explored most of the infrastructure for hosting tech events.

^{Photo by GLPH.Media (in Russian) circa 2012}

I think one of the most prevalent local trends is the rise of co-working spaces. Today, there are dozens of great spaces that take $230—$250 per month for a working desk and that allow residents to attend local meetups with top industry experts in biz dev, programming, design, and more. So next is probably the co-living trend that is just starting to find its way back into Moscow.

LAMA: Some people think only of music when they see the letters SXSW, but the brand is big news for startups. Can you explain a little about your work on the SXSW board?

dmitrykabanov: It’s a great question, because today «South by» is one of the biggest cultural conglomerates, covering everything at the intersection of tech and pop culture: film and music industries, startups, and more. I myself was invited to join the advisory board to judge and review startups applying for the Pitch event and Release IT event. In fact, I've gone through 500+ submissions in one night and carefully analyze proposed business models, and check out product prototypes.

For me, it was a real pleasure to see startups trying to solve real-world problems and people doing things they love. What’s more important, apart from judging, is that I had a chance to connect people with organizers and even help some of my friends visit “South by” and meet some of the industry leaders. So it was a real pleasure to judge, open doors, and introduce people.

LAMA: Why have you decided to storytell more on the co-work and co-live gigs?

dmitrykabanov: At the moment, I'm covering local startup gigs and both the co-work and co-live infrastructure. The topic has gained enormous traction around the globe and is now truly powering the new culture for Next Generation entrepreneurs. To be part of this movement, we decided to try lead it from the standpoint of storytelling and content creation — things that we do best.

---

Related reading:

^{The History of SXSW: How It All Started
Techstars Startup Digest: From Launch to Today
How the Early Success Stories Shaped the Modern Tech Industry}

Let's block ads! (Why?)

[Из песочницы] На пальцах: ассоциированные типы в Rust и в чём их отличие от аргументов типов

Для чего в Rust есть ассоциированные типы (associated types), и в чём их отличие от аргументов типов (type arguments aka generics), ведь они так похожи? Разве недостаточно только последних, как во всех нормальных языках? У тех, кто только начинает изучать Rust, а особенно у людей, пришедших из других языков ("Это же дженерики!" — скажет умудрённый годами джавист), такой вопрос возникает регулярно. Давайте разбираться.

TL;DR Первые контролирует вызываемый код, вторые — вызывающий.

Дженерики vs ассоциированные типы

Итак, у нас уже есть аргументы типов, или всеми любимые "дженерики". Выглядит это примерно так:

trait Foo<T> {
    fn bar(self, x: T);
}

Здесь T как раз и есть аргумент типа. Вроде бы этого должно быть достаточно всем (как 640 килобайт памяти). Но в Rust же есть ещё и ассоциированные типы, примерно такие:

trait Foo {
    type Bar; // Это ассоциированный тип
    fn bar(self, x: Self::Bar);
}

На первый взгляд те же яйца, но с другого ракурса. Зачем понадобилось вводить в язык ещё одну сущность? (Которой, кстати, в ранних версиях языка и не было.)

Аргументы типов — это именно аргументы, это означает что они передаются трейту в месте вызова, и контроль над тем, какой именно тип будет использован вместо T, принадлежит вызывающей стороне. Даже если мы в месте вызова не укажем явно T, это сделает за нас компилятор, используя выведение типов. То есть неявно всё равно этот тип будет выведен на вызывающей стороне и передан как аргумент. (Разумеется, всё это происходит во время компиляции, а не в рантайме.)

Рассмотрим пример. В стандартной библиотеке есть трейт AsRef, который позволяет одному типу на время прикинуться другим типом, преобразуя ссылку на себя в ссылку на что-то другое. Упрощённо этот трейт выглядит так (в реальности он чуть сложнее, я намеренно убрал всё лишнее, оставив лишь минимально необходимое для понимания):

trait AsRef<T> {
    fn as_ref(&self) -> &T;
}

Здесь тип T передаётся вызывающей стороной как аргумент, даже если это происходит неявно (если компилятор выведет этот тип за вас). Иными словами, именно вызывающая сторона решает, каким новым типом T будет прикидываться наш тип, реализующий этот трейт:

let foo = Foo::new();
let bar: &Bar = foo.as_ref();

Здесь компилятор, используя знание bar: &Bar, будет использовать реализацию AsRef<Bar> для вызова метода as_ref(), потому что именно тип Bar требуется вызывающей стороне. Само собой, что тип Foo должен реализовывать трейт AsRef<Bar>, и помимо этого он может реализовать ещё сколько угодно других вариантов AsRef<T>, среди которых вызывающая сторона и выбирает нужный.

В случае с ассоциированным типом всё с точностью до наоборот. Ассоциированный тип полностью контролируется тем, кто реализует данный трейт, а не вызывающей стороной.

Распространённый пример — итератор. Допустим, у нас есть коллекция, и мы хотим получить от неё итератор. Значения какого типа должен возвращать итератор? В точности того, который содержится в этой коллекции! Не вызывающая сторона должна решать, что вернёт итератор, а сам итератор лучше знает, что именно он умеет возвращать. Вот сокращённый код из стандартной библиотеки:

trait Iterator {
    type Item;
    fn next(&mut self) -> Option<Self::Item>;
}

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

Стоп. Ну и что? Всё равно непонятно, чем это лучше дженерика. Представим на минутку, что мы используем обычный дженерик вместо ассоциированного типа. Трейт итератора тогда будет выглядеть как-то так:

trait GenericIterator<T> {
    fn next(&mut self) -> Option<T>;
}

Но теперь, во-первых, тип T нужно снова и снова указывать в каждом месте где упоминается итератор, а во-вторых, теперь стало возможно реализовать этот трейт несколько раз с разными типами, что для итератора выглядит как-то странно. Вот пример:

struct MyIterator;

impl GenericIterator<i32> for MyIterator {
    fn next(&mut self) -> Option<i32> { unimplemented!() }
}

impl GenericIterator<String> for MyIterator {
    fn next(&mut self) -> Option<String> { unimplemented!() }
}

fn test() {
    let mut iter = MyIterator;
    let lolwhat: Option<_> = iter.next(); // Error! Which impl of GenericIterator to use?
}

Видите подвох? Мы не можем просто взять и вызвать iter.next() без приседаний — нужно обязательно дать компилятору знать, явно или неявно, какой тип будет возвращаться. Да и выглядит это неуклюже: зачем нам, на стороне вызова, знать (и сообщать компилятору!) тип, который вернёт итератор, тогда как это итератор должен лучше нас знать, какой тип он возвращает?! А всё потому, что мы смогли имплементировать трейт GenericIterator дважды с разным параметром для одного и того же MyIterator, что с точки зрения семантики итератора также выглядит нелепицей: с чего это вдруг один и тот же итератор может возвращать значения разных типов?

Если же вернуться к варианту с ассоциированным типом, то всех этих проблем можно избежать:

struct MyIter;

impl Iterator for MyIter {
    type Item = String;

    fn next(&mut self) -> Option<Self::Item> { unimplemented!() }
}

fn test() {
    let mut iter = MyIter;
    let value = iter.next();
}

Здесь, во-первых, компилятор без лишних слов правильно выведет тип value: Option<String>, а во-вторых, не получится реализовать трейт Iterator для MyIter второй раз с другим типом возвращаемого значения, и тем самым всё испортить.

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

trait IntoIterator {
    type Item;
    type IntoIter: Iterator<Item=Self::Item>;
    fn into_iter(self) -> Self::IntoIter;
}

И опять-таки, тут именно коллекция решает, какой это будет итератор, а именно: итератор, тип возвращаемого значения которого совпадает с типом элементов самой коллекции, и никакой другой.

Ещё более "на пальцах"

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

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

trait Add<RHS> {
    type Output;

    fn add(self, rhs: RHS) -> Self::Output;
}

Тут у нас есть "входной" аргумент RHS — это тип, к которому мы будем применять операцию сложения с нашим типом. И есть "выходной" аргумент Add::Output — это тот тип, который получится в результате сложения. В общем случае он может отличаться от типа слагаемых, которые, в свою очередь, тоже могут быть разных типов (к синему прибавить вкусное, и получить мягкое — а что, я так всё время делаю). Первый задан с помощью аргумента типа, второй — с помощью асоциированного типа.

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

Попробуем реализовать этот трейт:

use std::ops::Add;

struct Foo(&'static str);

#[derive(PartialEq, Debug)]
struct Bar(&'static str, i32);

impl Add<i32> for Foo {
    type Output = Bar;

    fn add(self, rhs: i32) -> Bar {
        Bar(self.0, rhs)
    }
}

fn test() {
    let x = Foo("test");
    let y = x + 42; // Компилятор преобразует это в вызов <Foo as Add>::add(42) для x
    assert_eq!(y, Bar("test", 42));
}

В этом примере тип переменной y определяется алгоритмом сложения, а не вызывающим кодом. Было бы очень странно, если бы было возможно написать что-то вроде let y: Baz = x + 42, то есть заставить операцию сложения вернуть результат какого-то постороннего типа. Как раз от таких вещей нас и страхует ассоциированный тип Add::Output.

Итого

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

Провалилась монетка? Добейте меня комментариями.

Let's block ads! (Why?)

YouTube отключил рекламу антивакцинаторам

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

Сейчас компания подтвердила свою линию и пошла ещё дальше. Она вообще отключила рекламу на каналах, посвящённых вреду вакцин и прививок. Согласно заявлению YouTube, данные материалы нарушают правила, запрещающие монетизацию видео с «опасным и вредным» контентом.

Таким образом, «антивакцинаторы» теряют важный источник финансирования и есть надежда, что некоторые из них свернут свою деятельность.
Справедливости ради нужно признать, что YouTube в данном случае не столько борется за справедливость, сколько следует мнению рекламодателей и общественности. В последнее время поднялась дискуссия, почему реклама известных брендов появляется в видеороликах против прививок. Ведь если провести логическую цепочку, то данные материалы имеют отношение к смертям тысяч людей, которые умерли из-за отказа от прививок от кори и других заболеваний. Обеспокоенные рекламодатели начали снимать рекламу из этих видеороликов, пишет BuzzFeed. Среди компаний, которые попросили отключить рекламу в видеороликах антивакцинаторов — ювелирная компания Brilliant Earth, разработчик программного обеспечения SolarWinds, магазин витаминов Vitacost и производитель марихуаны CWCBExpo.

Заметив такую тенденцию, YouTube принял решение полностью отключить рекламу антивакцинаторам.

«У нас есть строгие правила, которые регулируют, в каких видео разрешён показ рекламных объявлений. Видеоролики с контентом против вакцинации нарушают эти правила, — сообщил представитель YouTube. — Мы активно применяем эту политику, и если найдём видео, которое её нарушает, немедленно примем меры и удалим рекламу».

Проведённое ранее исследование показало, что YouTube выдаёт корректные результаты для запросов типа «безопасность вакцин» (ссылки на материалы от детских больниц и других медицинских учреждений и т. д.), но затем в списке рекомендаций для дальнейшего просмотра начинается мракобесие: зачастую там встречаются видеоролики антивакцинаторов с заголовками вроде «Мама изучила информацию о прививках, пришла в ужас и написала отказ».

Семь разных рекламодателей заявили, что не знали о размещении своей рекламы в таких видеороликах и обратилась к YouTube с просьбой прекратить это безобразие. Речь идёт о ряде каналов против прививок, включая VAXXED TV, LarryCook333 (сторонники движения StopMandatoryVaccinations_com), и iHealthTube. С тех пор YouTube запретил показ рекламы на всех этих каналах.

Кроме удаления рекламы, YouTube внедрил для антипрививочных каналов специальную информационную панель со ссылкой на вики-страницу «Антивакцинаторство». Такая панель раньше демонстрировалась только на видеороликах антивакцинаторов, где упоминались вакцины против кори, свинки и краснухи, а теперь её действие расширено на более длинный список прививок.

Ларри Кук, лидер антивакцинаторского движения StopMandatoryVaccinations, в своём Facebook подтвердил, что весь его канал демонетизирован, а YouTube даже не связался с ним и не сообщил об изменениях: «Очень жаль, что YouTube не видит ценности в рекламодателях, которые нацелены на очень большую и процветающую демографическую группу, которые верят в альтернативную медицину, целостное здоровье и природные лекарства, — сказал Кук. — Закрытие монетизации на каналах альтернативной медицины просто означает, что рекламодатели пойдут в другое место, чтобы достичь своей целевой аудитории».

После вспышки кори в США на прошлой неделе конгрессмен Адам Шифф потребовал от Facebook и Google рассмотреть риски распространения на своих платформах медицинской дезинформации о вакцинах. Facebook ответил, что «примет меры по сокращению распространения на Facebook дезинформации, связанной со здоровьем». Google напомнила об усилиях по кардинальной алгоритмической борьбе со всеми теориями заговора на YouTube: «Как и многие алгоритмические изменения, данные изменения в системе рекомендаций будут постепенными, а их точность будет уточняться со временем», — сказал представитель Google.

Всемирная организация здравоохранения назвала антивакцинаторство «одной из 10 глобальных угроз 2019 году» для здоровья и жизней людей. Например, По информации ВОЗ, за первое полугодие 2018 года корью заразилось более 41 тыс. жителей Европы: больше, чем за любой год предыдущего десятилетия. Компьютерное моделирование показало, что уменьшение на 5% количества привитых детей ведёт к трёхкратному росту заболеваемости.

Let's block ads! (Why?)