Всё то время, которое я работаю в Microsoft, я занимаюсь созданием инструментов для Linux-разработчиков. Я приступила к работе в августе 2016 года, после выпуска из Виргинского университета, где изучала информатику и менеджмент. Во время учёбы я программировала, в основном, на C++. Моей основной операционной системой была Linux.
Может показаться, что мой опыт не вполне соответствует тому, что может понадобиться Microsoft, но в то время компания претерпевала сильнейший сдвиг, как в плане технологий, так и в плане культуры. Компания переходила в новое состояние, в котором ей были важны все операционные системы, включая Linux.
Моя работа в Microsoft началась в команде Linux. Я занималась там продуктом SQL Server. Мне предложили присоединиться к этой команде, надеясь на то, что я принесу в неё мой опыт в сфере Linux. Я была под огромным впечатлением от того, что я, хотя только что отучилась, могу представлять ценность для команды из-за моего опыта.
Несколько лет назад идея о разработке разновидности SQL Server для Linux тянула бы лишь на первоапрельскую шутку, но в 2016 году это было совершенно реально. Я присоединилась к команде вскоре после того, как они выпустили первую версию продукта. Я занялась улучшением инструментария SQL Server, в частности, предназначенного для администраторов. Этот инструментарий был нацелен на управления Linux-серверами и приложениями. Использование SQL Server на Linux требовало приведения инструментов командной строки к тому виду, к которому привыкли пользователи Linux.
Кроме того, мне выпала возможность спроектировать первую версию графического интерфейса SQL Server для Linux. Я начинала работу с форка Visual Studio Code, который сегодня называется Azure Data Studio. Это — приложение, основанное на Electron, которое, независимо от операционной системы, может работать с любыми видами SQL Server.
Я многое узнала, занимаясь SQL Server для Linux в мой первый год работы в Microsoft. В эти знания я могу включить и освоение подхода к управлению разработкой и сопровождением проектов, основанного на комбинации технологий и бизнес-мышления.
Команда WSL, Chocolatey и Boxstarter на Microsoft Build 2018
В августе 2017 я присоединилась к команде WSL (Windows Subsystem for Linux, подсистема Windows для Linux) в качестве руководителя проекта. Впервые я услышала о WSL во время анонса на конференции Microsoft Build 2016. Соответствующее видео с Channel 9, «Running Bash on Ubuntu on Windows!», сразу после выпуска стало вирусным. Оно явно интересовало аудиторию сильнее, чем многие другие анонсы, сделанные на конференции. О технологии WSL кратко, буквально в течение пары минут, рассказали в рамках озвучивания основных тезисов конференции. Однако публика от этого прямо-таки сошла с ума, не говоря уже о журналистах. Был момент, когда команда, занимающаяся поддержкой Channel9, опасалась, что большая заинтересованность пользователей этим видеоклипом объяснялась, на самом деле, DDoS-атакой! Представитель компании Microsoft, запускающий Bash на Ubuntu, работающей внутри Windows… Это действо мгновенно стало хитом.
Первой командой, обнаружившей потребность пользователей в WSL, была та, которая работала над Windows Console. В ходе разработки им снова и снова приходилось слышать о том, что людям хочется чего-то, подобного Bash из Linux. В итоге команда пришла к следующей мысли: «Зачем делать что-то, напоминающее Bash, если можно просто сделать так, чтобы оболочка Bash запускалась бы прямо на Windows?».
Нельзя сказать, что сделать это было легко. Создание WSL потребовало комбинации глубокого знания Windows, которым обладала команда разработчиков ядра системы, и технологии, разработанной в Microsoft Research, которая называется пикопроцесс (picoprocess). Интересно то, что пикопроцессы, кроме того, являются той самой технологией, благодаря которой оказывается возможной работа SQL Server на Linux.
Пикопроцесс должен был обеспечивать работу немодифицированной реализации Linux в режиме пользователя. Команда, которая занимается ядром Windows, занялась разработкой шимов, предназначенных для соединения системных вызовов Linux с Windows. Другими словами, благодаря WSL стало возможно запускать код, скомпилированный для Linux, на ядре Windows NT. При этом не нужно было ни перекомпилировать код, ни пользоваться виртуальными машинами.
Мы не создали тогда лишь собственного дистрибутива Linux. Дело в том, что существовало множество таких дистрибутивов. Первой разновидностью Linux, доступной в WSL, стала Ubuntu. Мы связались со специалистами из Canonical для того чтобы узнать, захочется ли им помочь нам в работе над WSL. Они отнеслись к нашей идее с энтузиазмом. Это привело к тому, что Ubuntu появилась в Microsoft Store. Кстати, предыдущее предложение, само по себе, звучит достаточно необычно. Сейчас в Microsoft Store можно насчитать уже 6 дистрибутивов. Интересно, в каких ещё магазинах приложений, имеющихся в неких операционных системах, есть другие операционные системы?
Сейчас в Microsoft Store имеется 6 дистрибутивов Linux, которые можно использовать в WSL
Код, который мы тогда написали, представлял собой Linux-совместимые системные вызовы ядра, служащие интерфейсом между процессами Linux и ядром Windows. В Linux имеется около 340 системных вызовов. Вопрос был в том, чтобы решить, какие системные вызовы нужно реализовывать первыми. Как и в случае с любой операционной системой, в Linux новые системные вызовы добавляются по мере выхода новых версий ОС, но старые вызовы никогда не удаляются, что обеспечивает обратную совместимость. Сначала была реализована обработка некоего набора системных вызовов, а всё остальное было обёрнуто в события наподобие «ещё не реализовано». Это позволило команде WSL приступить к анализу того, какие именно системные вызовы нужны пользователям Linux.
Ответ на вопрос о том, какие системные вызовы нужно реализовывать в первую очередь, означал необходимость налаживания связи с теми людьми, которые пользовались бы WSL. Сообщение об этой технологии на конференции Build было направлено именно на то, чтобы люди начали бы пользоваться WSL и дали бы обратную связь. Для того чтобы обзавестись WSL, нужно было быть участником программы предварительной оценки Windows (Windows Insider Program). Подключиться к этой программе может кто угодно. Можно подумать, что участниками программы были только те, кому интересна Windows, но тогда, среди более чем десяти миллионов подписчиков, присутствовали люди с самыми разными интересами. Их интересовала не только Windows, но и, например, игры, и новые возможности Bluetooth, и WSL.
Одной из групп пользователей, заинтересованной в том, чтобы оболочка Bash работала бы на Windows, были веб-разработчики, занимающиеся созданием веб-приложений, запускающихся на Linux-серверах. Весь процесс по сборке их приложений часто представлял собой последовательность Bash-команд. Кроме того, если кто-то решит обратиться за помощью в сфере разработки веб-приложений, скажем, на Stack Overflow, большинство примеров кода, которые он сможет найти, будет предназначено для запуска на Linux. Это не особенно хорошо для тех, кто, в качестве компьютера для веб-разработки, использует Windows. Часто подобным разработчикам легче всего просто перейти на платформу Mac. На macOS подобные примеры кода запускаются без всяких проблем.
За первые пару недель присутствия WSL в Windows один корпоративный пользователь смог запустить XEyes. Эта программа выполнялась в оконной системе X11, работающей в WSL. XEyes — простая программа. Она выводит мультяшные глаза, которые следят за курсором мыши. Но эта демонстрация взорвала социальные сети.
Программа XEyes работает на Windows через WSL
Мы много обсуждали то, как именно мы хотим собирать отзывы пользователей о WSL. Традиционным инструментом, применяемым для сбора отзывов, был UserVoice. У нас был UserVoice-сайт, предназначенный для WSL, на котором набрались сотни идей и тысячи голосований по разным вопросам. Настоящий вопрос встал перед нами тогда, когда речь зашла о том, использовать ли нам GitHub. Так как одной из первых групп пользователей, заинтересованных в WSL, были веб-разработчики, вопрос о GitHub был очень важным. Но WSL не была опенсорсным проектом. Размещение подобного проекта на GitHub выглядит странно. Мы решили пойти разработчикам навстречу и создали на GitHub страницу для сообщений о проблемах, для отзывов и обсуждений. С тех пор мы получили тысячи сообщений, касающихся множества вопросов, связанных с использованием Linux в Windows.
Тысячи людей оставили сообщения об ошибках в GitHub-репозитории WSL. Каждое подобное сообщение было рассмотрено и обсуждено командой WSL, по каждому из них были даны комментарии. После этого принималось решение о дальнейших действиях. Если для того, чтобы реализовать некую возможность или исправить какую-то ошибку, нужно было написать новый код — этот код создавался и добавлялся в проект WSL, после чего попадал во все сборки Windows, распространяемые по программе Windows Insider. Весь цикл, от получения сообщения об ошибке, до её исправления, занимал не особенно много времени — порядка пары недель.
В итоге, благодаря оперативной реакции команды WSL на обращения пользователей, можно было говорить о том, что сообщество принимает участие в процессе создания WSL. Люди сообщали о проблемах или о своих пожеланиях через UserVoice или GitHub, команда всё это рассматривала и вносила в проект изменения, которые затем появлялись в сборках проекта Windows Insider.
Когда я вошла в команду WSL в роли руководителя проекта, я сосредоточила свои усилия на том, чтобы вывести WSL из состояния бета-версии. Жалобы пользователей, в основном, касались совместимости и производительности. Но, по-моему, если пользователи беспокоятся о таких вещах, это значит, что они используют нашу разработку всерьёз. О производительности заботятся лишь те, кто решает с помощью некоей программной системы какие-то большие задачи. В результате, хотя нам многое ещё нужно было сделать, делали мы это не просто так, а ради того, чтобы люди получили бы возможность решать больше задач с помощью WSL, и ради того, чтобы они смогли бы решать свои задачи быстрее.
По мере того, как возможности WSL начали расширяться, мы приложили усилия к тому, чтобы приблизить WSL к разработчикам, а не только к тем пользователям, которые традиционно работают, применяя экосистему Microsoft. Очень интересно было посещать мероприятия наподобие PyCon и OSCON. Разработчики, которые там присутствовали, были удивлены тому, что участие в этих мероприятиях принимают и представители Microsoft. Разработчики с недоверием относились к идее запуска Linux в среде Windows. На этих мероприятиях я показывала SQL Server, WSL и Visual Studio Code.
Демонстрация WSL на различных мероприятиях
Я отвечала на их скептические замечания предложением попробовать то, что я им демонстрировала. Когда сомневающиеся начинали выполнять собственные команды, небольшие скрипты и сниппеты, я всегда встречалась с бурной реакцией на происходящее: «Постойте, а это и правда Linux. Как вы это сделали? Почему я об этом не знал?». Часто они приходили к выводу о том, что мы создали нечто, соответствующее их потребностям, нечто такое, что выглядит весьма интересно.
Мы учли жалобы пользователей, касающиеся совместимости и производительности WSL, и выпустили новую архитектуру системы — WSL 2. Она обеспечивает полную совместимость благодаря включению в Windows ядра Linux и даёт 20-кратный прирост скорости. Я получила интереснейшие впечатления, создавая основу WSL 2 и наблюдая за анонсом этой технологии на конференции Build, которая прошла в мае 2019 года. Сегодня проект WSL уже перерос бета-версию и добрался до версии 2.
Кроме того, я работала в Microsoft с другими командами, стремясь к тому, чтобы WSL можно было бы использовать и с их продуктами. Одним из значительных примеров подобного использования WSL можно назвать Visual Studio Code. Это — самая популярная среда для работы с кодом, используемая при разработке JavaScript и Node.js-проектов. Я заинтересовалась Visual Studio Code тогда, когда я поняла, что разработчики, использующие этот редактор, могут получить значительные преимущества от WSL. Поначалу речь не шла о необходимости писать огромные объёмы кода. Основной задачей было упрощение отладки Node.js-программ, выполняемых в среде WSL. Это дало бы разработчикам возможность разрабатывать программы, рассчитанные на Linux-версию Node.js, на Windows-компьютере с использованием WSL. Отладка таких программ выглядела бы точно так же, как их отладка в Linux.
Первая попытка интеграции Visual Studio Code с WSL и Node.js
После того, как подобное оказалось возможным для JavaScript и Node.js, к нам стало поступать множество запросов на то, чтобы нечто похожее было бы сделано и для других языков, скажем, для C++ и Python. Меня восхитил этот пример интеграции WSL и VS Code, я обнаружила, что мне всё это чрезвычайно интересно. Это привело меня к моей новой роли в сфере создания инструментов для Linux-разработчиков. Сейчас я уделяю основное внимание инструментам для C++-разработчиков в VS Code. В этой работе я, конечно, ориентируюсь на Linux. Приятно было видеть демонстрацию системы Visual Studio Code Remote Development на мероприятии PyCon в этом году, когда было выпущено соответствующее расширение WSL. Тогда же было представлено и расширение для C++, разработкой которого занималась моя команда.
Несмотря на то, что я провела в Microsoft не так уж и много времени, меня радует то, что мне удалось поучаствовать в создании множества инструментов для Linux-разработчиков. Это и базы данных, и поддержка Linux в Windows, и средства для написания и отладки кода. Я планирую и дальше заниматься Linux и создавать инструменты, которыми с удовольствием будут пользоваться разработчики во всём мире.
Уважаемые читатели! Пользуетесь ли вы WSL?
Автор: ru_vds
