Русский
Русский
English
Статистика
Реклама

Разработка

Перевод Видеодомофон, основанный на Raspberry Pi

16.02.2021 16:13:42 | Автор: admin
Автор статьи, перевод которой мы сегодня публикуем, хочет поделиться рассказом о создании видеодомофона, основанного на Raspberry Pi 3. Устройство работает в паре с iOS-телефоном, отправляя на него Push-уведомления когда кто-то нажимает на кнопку домофона. Система позволяет увидеть гостя и поговорить с ним.



Компоненты


Аппаратные компоненты:


Программы:


Инструменты:


Обзор проекта


Случилось так, что я наткнулся на хорошие программы, которые, на основе Raspberry Pi, позволяют сделать видеодомофон. Потом мне удалось уместить все компоненты домофона в компактный корпус. В результате у меня получилось интересное устройство, инструкцию по созданию которого я привожу в этом материале.

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

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

Шаг 1: подготовка и сборка аппаратных компонентов


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


Схема расположения отверстий, которые нужно просверлить в корпусе

Теперь просверлите в корпусе три маленьких отверстия, которые позволят слышать звук громкоговорителя.

Далее просверлите большое отверстие, расположенное в правой верхней части корпуса. Там будет кнопка домофона. Прежде чем сверлить это отверстие подберите сверло, диаметр которого соответствует диаметру выбранной вами кнопки.


Сверление отверстия для кнопки

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


Обработка краёв отверстия

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


Окраска корпуса

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


Укороченные провода для громкоговорителя

Припаяем пару соединительных проводов к кнопке.


Припаивание проводов к кнопке

Сейчас все компоненты нашей системы готовы к установке в верхнюю часть корпуса. Начнём монтаж компонентов с кнопки.


Установка кнопки в верхнюю часть корпуса

Теперь поставим на место громкоговоритель. А именно: подключим к нему провода, снимем защитную плёнку с клейкой подложки и, прижав, зафиксируем его там, где он должен быть.


Установка громкоговорителя

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


Установка модуля камеры

Подключим громкоговоритель к плате Raspberry Pi. Для этого надо взять ещё один соединительный провод, разрезать его, взять ту его часть, на которой имеется Male-разъём (его, в результате, можно будет подключить к Female-разъёму провода, идущего от громкоговорителя), зачистить конец провода и пропустить его через отверстие около аудиовыхода платы.


Подготовка соединительного провода для подключения громкоговорителя к плате

Теперь надо припаять этот провод к контактной площадке, к которой припаян один из контактов аудиовыхода платы.


Припаивание провода к аудиовыходу

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


Контактная площадка, к которой нужно припаять провод

Теперь нужно установить Raspberry Pi в нижнюю часть корпуса и подключить к плате все остальные провода.


Установка платы в нижнюю часть корпуса и подключение к ней проводов

На следующем рисунке показана схема GPIO-пинов Raspberry Pi 3.


Схема GPIO-пинов Raspberry Pi 3

После этого можно закрыть корпус и перейти к следующему шагу.

Шаг 2: установка свежей ОС на Raspberry Pi


Загрузите и распакуйте архив с операционной системой Raspbian Stretch для Raspberry Pi 3 (или 3+).

По-видимому, самую свежую версию Raspberry Pi OS устанавливать не стоит, так как у её аудиоподсистемы есть одна проблема. Я, правда, надеюсь, что в обозримом будущем с этой проблемой справятся.

Загрузите и установите программу Raspberry Pi Imager.

Подключите к компьютеру microSD-карту и отформатируйте её. После этого запустите Raspberry Pi Imager.

Нажмите на кнопку CHOOSE OS, позволяющую выбрать операционную систему для записи на карту, и выберите вариант Use custom. После этого укажите программе путь к распакованному файлу Raspbian Stretch.

Выберите карту, воспользовавшись кнопкой CHOOSE SD CARD, а после этого нажмите на кнопку WRITE.

После того, как запись образа ОС на карту будет завершена, подключите карту к плате Raspberry Pi.

Подключите к Raspberry Pi монитор, пользуясь HDMI-кабелем, USB-мышь и клавиатуру. После этого подайте на плату питание.

Шаг 3: настройка WiFi и камеры на Raspberry Pi


После того, как ОС на Raspberry Pi запустится, воспользуйтесь средствами её первоначальной настройки и подключите плату к WiFi.

Затем щёлкните по значку Raspberry в верхней левой части экрана, а после этого перейдите в раздел Preferences и щёлкните по Raspberry Pi Configuration. Щёлкните по Interfaces, включите камеру, нажмите на кнопку OK и согласитесь с перезагрузкой устройства.

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


Значок запуска консоли

Выполните в консоли следующую команду:

raspistill -o cam.jpg

Откройте File Manager с помощью соответствующего значка.


Значок менеджера файлов

Найдите файл cam.jpg, откройте его двойным щелчком и просмотрите, удостоверившись в том, что камера работоспособна.

Шаг 4: настройка и проверка громкоговорителя


Щёлкните правой кнопкой мыши по значку Volume, который находится в правой верхней части экрана, и выберите Analog. После этого щёлкните по тому же значку левой кнопкой мыши и установите громкость звука. Рекомендую установить её в 80%.

Далее снова откройте консоль и выполните следующую команду:

speaker-test

В ответ на эту команду система должна воспроизвести белый шум.

Если вы хотите испытать воспроизведение чего-то более осмысленного выполните в консоли следующую команду:

aplay /usr/share/sounds/alsa/Front_Center.wav

Будет воспроизведена запись человеческого голоса.

Шаг 5: настройка микрофона


Снова щёлкните правой кнопкой мыши по значку Volume, а после этого по USB Device Settings.

Затем щёлкните по выпадающему меню Sound card и выберите USB PnP sound device.

Щёлкните по Select Controls и выберите Microphone и Auto Gain Control. После этого щёлкните по Close.

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

К этому моменту аппаратная часть проекта собрана, настроена и готова к работе. Поэтому мы переходим к его программной части.

Шаг 6: загрузка Seajei SDK и запуск приложения-примера на Raspberry Pi


Откройте браузер Raspberry Pi и перейдите по адресу seajei.com.

Если понадобится прокрутите страницу и щёлкните по ссылке Free SDK.

На следующей странице воспользуйтесь ссылкой Download SDK для загрузки SDK. Соответствующий файл попадёт в папку Downloads.

Откройте File Manager и перейдите в папку Downloads.

Щёлкните правой кнопкой мыши по .zip-файлу с материалами SDK и выберите команду распаковки архива. После этого переместите папку SDK на рабочий стол.

Теперь откройте консоль и перейдите в папку примера Doorbell, выполнив команду, подобную следующей:

cd Desktop/Seajei-3.1.8/SamplePrograms/RaspberryPi/Doorbell

Вам, возможно, придётся поменять имя папки Seajei-3.1.8 на другое, соответствующее вашей версии Seajei SDK.

Посмотрите файл README, открыв его следующей командой:

cat README

Затем, в соответствии с инструкциями из этого файла, выполните команду sudo apt update. После этого выполните другую sudo-команду, описанную там. Вот команды, о которых идёт речь:

sudo apt update; sudo apt install libopus-dev libssl-dev portaudio19-dev

После того, как работа этих команд завершится, запустите сборочный скрипт, рассчитанный на Raspberry Pi 3:

./build_pi_3_4.sh

А теперь можно запустить исполняемый файл примера:

./doorbell

Запишите ID (идентификатор) устройства. Он вам понадобится для подключения к домофону из iOS-приложения. В моём случае идентификатор выглядел так: vmy9dj.

Сейчас подходящий момент для проверки кнопки. Нажмите на неё несколько раз. Если она работает правильно вы увидите сообщение Button triggered.

Шаг 7: запуск приложения-примера на iOS


Теперь наладим работу iOS-части домофона. Тут я исхожу из предположения о том, что у вас уже установлен редактор XCode и есть учётная запись разработчика Apple.

Откройте сайт seajei.com на своём Mac и загрузите SDK.

Распакуйте загруженный архив и перейдите в папку SamplePrograms/iOS/SeajeiDemoApp. Откройте файл SeajeiDemoApp.xcodeproj в XCode.

Заполните поле Team на вкладке Signing & Capabilities для того чтобы вы могли бы собрать проект. Затем выберите цель сборки. Это может быть симулятор или iOS-устройство. Скомпилируйте приложение и запустите его

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

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

Шаг 8: наладка работы push-уведомлений


Сразу скажу, что для работы уведомлений нужно iOS-устройство. В симуляторе уведомления работать не будут.

Вернёмся к материалам Seajei SDK и откроем файл SeajeiDeveloperGuideIOS.pdf. В этом документе имеется раздел, посвящённый push-уведомлениям. Выполним инструкции из этого раздела, после чего в нашем распоряжении окажется .p12-файл. Его надо отправить по адресу support@seajei.com. В ответ пришлют токен. У меня этот токен оказался меньше чем через день.

После того, как вы получили токен (выглядит он как строка разных символов), вернитесь на Raspberry Pi, откройте консоль и войдите в папку программы-примера Doorbell:

cd Desktop/Seajei-3.1.8/SamplePrograms/RaspberryPi/Doorbell

Теперь надо отредактировать файл doorbell.c. Например для этого можно воспользоваться редактором geany, открыв файл такой командой:

geany doorbell.c

В этом файле нужно найти то место, где введён пробный токен, и заменить его на собственный. После этого, сохранив файл и выйдя из редактора, надо снова воспользоваться скриптом build_pi_3_4.sh. Когда он отработает можно запустить программу.

Сейчас вернёмся к iOS-приложению и внесём в файл PhoneAppViewController.m тот же токен. После изменения этого файла приложение нужно перекомпилировать и запустить, а после его запуска надо снова ввести ID устройства. Если ID там уже присутствует то, скорее всего, вам нужно коснуться соответствующего поля и закрыть диалоговое окно. Иначе приложение может и не заработать так, как нужно.

Если теперь нажать на кнопку домофона на телефон должно прийти уведомление.


Уведомление, пришедшее на телефон от домофона

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

Шаг 9: организация автоматического запуска программы на Raspberry Pi


Вернёмся на Raspberry Pi и войдём в уже знакомую нам папку:

cd Desktop/Seajei-3.1.8/SamplePrograms/RaspberryPi/Doorbell

Снова откроем файл README:

cat README

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

cp doorbell /home/pi/Desktop; sudo cp raspidoorbell.service /lib/systemd/system; sudo systemctl start raspidoorbell.service; sudo systemctl enable raspidoorbell.service

Если система вас об этом попросит выполните следующую команду:

sudo systemctl daemon-reload

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

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

sudo systemctl stop raspidoorbell.service

Шаг 10: возьмите себе чего-нибудь выпить


Отпразднуйте успешное завершение проекта вы это заслужили.

Планируете ли вы сделать видеодомофон на основе Raspberry Pi?
Подробнее..

Перевод Разработка Diablo IV в Blizzard и отладка дампов памяти из Linux в Visual Studio

18.02.2021 16:06:37 | Автор: admin
В блоге Microsoft недавно была опубликована статья, которую написал Билл Рэндольф, старший инженер-программист Blizzard, занимающийся разработкой Diablo IV. В этой статье раскрыты некоторые особенности работы над Diablo IV и, в частности, рассказано об использовании Visual Studio для отладки кода, рассчитанного на Linux. Сегодня мы предлагаем вашему вниманию перевод этого материала.


Введение


Мы, работая над Diablo IV, пишем весь код в Windows, а потом компилируем его для разных платформ. Это относится и к нашим серверам, которые работают под управлением Linux. (Код включает в себя директивы условной компиляции и, там, где это нужно, в нём есть фрагменты, написанные специально для конкретной платформы.) Наша работа организована именно так по многим причинам. Для начала ключевые профессиональные навыки нашей команды относятся к Windows. Даже наши серверные программисты лучше всего знакомы именно с Windows-разработкой. Мы ценим возможность применения одних и тех же инструментов и одной и той же базы знаний всеми программистами нашей команды.

Ещё одна, самая важная причина того, что мы занимаемся разработкой на Windows, заключается в возможности пользоваться высокофункциональным и надёжным набором инструментов, который даёт нам Visual Studio. И даже если бы мы разрабатывали что-то в Linux, то я могу сказать, что в мире Linux нет ничего такого, что можно было бы хотя бы сравнить с Visual Studio.

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

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

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


О применяемом нами процессе отладки кода


Отладка Linux-кода в Visual Studio возможна лишь в том случае, если в системе установлена подсистема Windows для Linux (WSL), или тогда, когда в менеджере подключений (Connection Manager) настроено подключение к Linux. Все наши серверные разработчики установили WSL, используя дистрибутив, на котором мы разворачиваем наш проект. Мы запускаем написанный мной скрипт, который устанавливает все инструменты разработки и вспомогательные библиотеки, необходимые для сборки нашего сервера в WSL.

(Ненадолго отвлекусь от нашей основной темы. Мне хотелось бы подчеркнуть, что мы пришли к выводу о том, что WSL это лучшее из существующих окружений, позволяющих разработчикам тестировать изменения в Linux-сборках. Крайне удобно выглядит такая схема работы: переход в WSL, использование команды cd для входа в общую директорию с кодом и сборка проекта прямо оттуда. Это гораздо лучшее решение, чем использование виртуальной машины или даже контейнера. Если вы собираете проекты с использованием CMake, это значит, что вы, кроме того, можете задействовать встроенную в Visual Studio поддержку WSL.)

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

Когда один из серверов нашей инфраструктуры даёт сбой, нас об этом уведомляет специальный скрипт, после чего файлы дампа записываются в общую сетевую папку. Для отладки этих файлов, либо в Linux, либо в Visual Studio, необходима работающая программа. При отладке полезно использовать в точности те общие библиотеки, которые применялись в развёрнутом контейнере. Для получения этих файлов мы используем другой скрипт. Сначала мы копируем дамп на локальную машину, а потом запускаем скрипт и передаём ему сведения об этом дампе. Скрипт загружает контейнер Docker, который был собран для исследуемой версии кода, извлекает из него исполняемые файлы нашего сервера, а так же определённые общие библиотеки времени выполнения. Всё это нужно для gdb. (Это, при работе с gdb, позволяет избежать проблем с совместимостью, которые могут возникнуть в том случае, если WSL-версия системы не является точно такой же, как её развёрнутая Linux-версия.) Скрипт, настраивая отладочную сессию, пишет данные в ~/.gdbinit, указывая, что общие библиотеки являются системными библиотеками.

Потом мы переходим в Visual Studio, где и начинается самое интересное. Мы загружаем решение для сборки Windows-версии наших серверов. Затем мы открываем новое диалоговое окно отладки, воспользовавшись командой Debug -> Other Debug Targets -> Debug Linux Core Dump with Native Only. Мы устанавливаем флажок Debug on WSL и вводим пути к файлам дампа и к серверным бинарникам (предназначенным для WSL!). После этого достаточно нажать на кнопку Debug и наблюдать за происходящим.


Запуск отладки в Visual Studio

Visual Studio самостоятельно запускает gdb в WSL. После того, как некоторое время система поработает с диском, выводится стек вызовов программы, давшей сбой, а указатель инструкций устанавливается на соответствующую строку кода. Это, воистину, дивный новый мир!

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

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

А вот Visual Studio даёт нам значительно более мощные возможности, чем имелись у нас раньше. В многопоточных средах можно открыть в отладочной сессии окно Threads и, пощёлкав по потокам, посмотреть их стеки. Это, правда, очень похоже на подход, используемый в gdb. Поэтому, если надо изучить, скажем, 50 потоков, это может превратиться в довольно трудоёмкую и скучную задачу. К счастью, в Visual Studio есть инструмент, значительно упрощающий эту задачу. Речь идёт об окне Parallel Stacks.

Признаю: большинство из нас не знали о Parallel Stacks до тех пор, пока Эрика Свит и её команда не сказали нам об этом. Если во время работы отладочной сессии выполнить команду Debug -> Windows -> Parallel Stacks будет открыто новое окно, которое выводит сведения о стеке вызовов каждого потока в исследуемом процессе. Это нечто вроде вида с высоты птичьего полёта на всё пространство процесса. По любому кадру стека любого потока можно сделать двойной щелчок. После этого Visual Studio перейдёт в этот кадр и в окне исходного кода, и в окне стека вызовов. Это очень сильно помогает нам экономить время.

После того, как мы видим код, находящийся поблизости от места сбоя, мы можем исследовать переменные с использованием мыши, с помощью QuickWatch, или применив любой другой из множества инструментов Visual Studio. Конечно, в релизных сборках многие переменные подвергаются оптимизации, но, в то же время, многие не подвергаются! Мы, применяя интерфейс Visual Studio, можем выявить проблему гораздо быстрее, чем раньше, используя gdb.



Итоги


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

Какие возможности Visual Studio вы считаете самыми полезными?

Подробнее..

Перевод Использование Redis в инфраструктурных микросервисах

19.02.2021 16:11:01 | Автор: admin
В 2019 году я писал о том, как создать хранилище событий, основанное на Redis. Я рассказывал о том, что потоки Redis хорошо подходят для организации хранения событий, так как они позволяют хранить события с использованием иммутабельного механизма, напоминающего журнал транзакций, поддерживающего только присоединение новых данных к уже имеющимся, но не изменение существующих данных. Теперь же, используя обновлённое приложение OrderShop, речь о котором шла в вышеупомянутом материале, я хочу продемонстрировать пример использования Redis для организации работы очереди событий, продолжая рассказывать о возможностях применения Redis Enterprise, выходящих за пределы кеширования.



Обзор микросервисов, инфраструктурных сервисов и распределённых систем


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

В распределённых системах используется и распределённое состояние приложений. В соответствии с теоремой CAP в любой реализации распределённых вычислений возможно обеспечить не более двух из трёх следующих свойств: согласованность данных (consistency), доступность информации (availability) и устойчивость к разделению (partition tolerance) (первые буквы английских наименований этих свойств и сформировали акроним CAP). Получается, что для того чтобы сделать свою реализацию распределённой системы устойчивой к отказам, необходимо выбирать между доступностью информации и согласованностью данных. Если мы выберем доступность информации то, в итоге, в нашем распоряжении окажется то, что называют согласованностью в конечном счёте (eventual consistency). То есть данные будут согласованными, но лишь через некоторое время после последнего обновления. А если выбрать согласованность данных это окажет воздействие на производительность, так как возникнет необходимость в синхронизации и изоляции операций записи данных во всей распределённой системе.

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

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

Проект OrderShop: пример реализации распределённой системы электронной коммерции


OrderShop это своего рода Hello World из сферы микросервисных архитектур, простая реализация системы электронной коммерции, в которой используется подход, основанный на событиях. Этот демонстрационный проект использует простую модель домена, но данная модель удовлетворяет нуждам приложения. Здесь мы будем рассматривать вторую версию OrderShop.

Оркестровка OrderShop выполняется с использованием Docker Compose. Все сетевые коммуникации основаны на gRPC. Центральными компонентами системы являются Event store (хранилище событий) и Message queue (очередь событий). Абсолютно все сервисы подключены только к ним по gRPC. Код OrderShop написан на Python. Вот GitHub-репозиторий проекта. Обратите внимание на то, что этот проект не рассчитан на продакшн-использование. Это лишь учебный пример распределённой системы.

Работа с OrderShop v2


Сначала клонируйте GitHub-репозиторий проекта. После этого вы сможете выполнять различные действия. А именно:

  1. Для запуска приложения используйте команду docker-compose up.
  2. Если после запуска приложения открыть браузер и перейти по адресу http://localhost:5000/, можно будет наблюдать за событиями и анализировать состояние проекта.
  3. Запустить клиент можно командой python -m unittest tests/unit.py.
  4. Если открыть другую вкладку браузера и перейти по адресу http://localhost:8001/ можно будет, использовав redis:6379, подключиться к тестовой базе данных.
  5. Для остановки приложения воспользуйтесь командой docker-compose down.

Архитектура OrderShop v2


В нашем случае серверная архитектура проекта состоит из нескольких сервисов. Состояние приложения распределено по нескольким доменным сервисам, но хранится в едином хранилище событий. В компоненте Read model (модель чтения) сосредоточена логика чтения и кеширования данных.


Архитектура и потоки данных приложения OrderShop v2

Команды и запросы передаются через компонент Message queue. А передача событий осуществляется через компонент Event store, который, кроме прочего, играет роль шины событий.

Инфраструктурные сервисы


В OrderShop v2 все одноадресные передачи данных выполняются через компонент Message queue. Для реализации этого механизма используются списки Redis (Redis List), в частности два списка, объединённые в так называемую надёжную очередь (reliable queue). Система обрабатывает простые команды (например операции, затрагивающие единственную сущность) синхронно, а команды, на выполнение которых нужно длительное время (например операции пакетной обработки данных, операции, выполняемые при работе с почтой) асинхронно и, в исходном виде, умеет реагировать на синхронные сообщения.

Компонент Event store основан на потоках Redis (Redis stream). Доменные сервисы (в нашем случае это просто макеты реальных сервисов, используемые для демонстрации функционала OrderShop) подписаны на потоки событий, имена которых соответствуют именам тем событий (то есть именам сущностей) и отправляют события в эти потоки. Каждое событие это элемент потока, которому назначена временная метка события, играющая роль ID. Совокупность всех событий, отправленных в потоки, представляет собой состояние всей системы.

Сервисы приложения


Компонент Read model кеширует полученные из Event store сущности в Redis, используя модель домена. Несмотря на использование кеша это система, не хранящая состояние.

Компонент API gateway (шлюз API) тоже не хранит состояние и обслуживает REST-API на порте 5000. Он перехватывает HTTP-соединения и перенаправляет их либо к компоненту Read model для чтения данных из состояния приложения (для выполнения запросов), либо к выделенным доменным сервисам для записи данных в состояние (для выполнения команд). Это концептуальное разделение между операциями чтения и записи данных представляет собой паттерн, называемый Command Query Responsibility Segregation (CQRS). При применении этого паттерна код, изменяющий состояние приложения, отделяется от кода, читающего это состояние.

Доменные сервисы


Доменные сервисы получают команды на запись данных от компонента API gateway через компонент Message queue. После успешного выполнения команды они отправляют соответствующее событие в компонент Event store. А операции чтения, в свою очередь, обрабатываются компонентом Read model, который получает сведения о состоянии от компонента Event store.

CRM service (Customer Relation Management service, сервис системы управления взаимоотношениями с клиентами) это компонент, не хранящий состояние. Он подписан на доменные события из хранилища событий и отправляет клиентам электронные письма, используя Mail service (почтовый сервис).

Центральная доменная сущность называется Order (заказ). У неё есть поле, называемое status, указывающее на состояние заказа. Переходы между состояниями осуществляются с использованием конечного автомата. Это показано на следующем рисунке.


Состояния, в котором может пребывать заказ

Эти переходы выполняются в нескольких обработчиках событий, которые подписаны на доменные события (тут используется паттерн SAGA).

Клиенты


Работа клиентов имитируется с использованием фреймворка для проведения модульных тестов из Python. В настоящий момент реализовано 10 модульных тестов. Узнать подробности об этом можно, заглянув в файл tests/units.py.

Если обратиться к порту 5000 можно увидеть простой интерфейс, используемый для наблюдения за событиями и для просмотра состояния приложения (с использованием WebSockets).

Для взаимодействия с экземпляром Redis можно использовать контейнер RedisInsight, обратившись к нему по адресу http://localhost:8001/ и воспользовавшись redis:6379 для подключения к тестовой базе данных.


RedisInsight удобное средство для работы с базами данных Redis

Итоги


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

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

Как вы используете Redis?

Подробнее..

Перевод Мир JavaScript в 2021 году

23.02.2021 12:21:01 | Автор: admin
Мир веб-разработки весьма изменчив. Изменения в нём происходят очень быстро. Что принесёт в него 2021 год? Здесь я хочу поделиться выводами о грядущих крупных JS-трендах, которые я сделал, проанализировав соответствующие исследования, проведённые в 2020 году.




Сначала пара слов о самих этих исследованиях. К сожалению, какое-то время нам придётся обходиться без свежих материалов отличного Front End Tooling Survey. Это усложняет поиск трендов. И хотя в этом году на одно хорошее исследование стало меньше, вместо него появилось одно новое The State of Front End. Но оно проводится первый год, поэтому в нашем распоряжении нет его данных за прошлые годы, что, опять же, не способствует облегчению задачи поиска трендов. Правда, в нём приняло участие внушительное количество разработчиков со всего мира (4500), что, определённо, делает его ценным источником информации.

Менеджеры пакетов


В прошлом году я предлагал понаблюдать за развитием PNPM. Этот менеджер рассчитан на недопущение конфликтов версий пакетов и хорошо показывает себя при работе с монорепозиториями. Существуют люди, которые очень им увлечены, в прошлом году его репозиторий набрал 9500 звёзд на GitHub. PNPM, совершенно очевидно, привлёк на свою сторону немало разработчиков. Но мне кажется, что в 2021 году он вряд ли сможет серьёзно конкурировать с другими менеджерами пакетов. Дело в том, что Yarn и NPM используются в огромном множестве реальных проектов, и в том, сколько энергии команды разработчиков обоих этих проектов тратят на их развитие, на оснащение их новыми возможностями. Появление некоторых из этих новшеств стало непосредственной реакцией на наличие аналогичных возможностей у PNPM. Например это Рабочие области (Workspaces) Yarn. Это показывает важность конкуренции в развитии опенсорса.

Тестирование


В 2019 году Cypress и Puppeteer стали заметными новыми инструментами. Их успех продолжился и в 2020. Но Microsoft выпустила новый инструмент для сквозного тестирования, Playwright. Такое ощущение, что он появился буквально ниоткуда, но в 2020 году он набрал почти 20 тысяч звёзд на GitHub. У Microsoft, у самой большой в мире компании, занимающейся разработкой ПО, есть возможности для широкого продвижения своих разработок. Но это лишь частично объясняет популярность Playwright. Главная причина его популярности богатый функционал и возможность лёгкого перехода на него с Puppeteer.


Playwright возглавляет список тестировочных фреймворков. И это несмотря на то, что в 2019 году о нём ещё никто не знал

С тех пор как Сатья Наделла стал CEO Microsoft, у компании появился обычай выпускать популярные и мощные опенсорсные инструменты. Например VS Code.

Разновидности JavaScript


В прошлом году я говорил о том, что TypeScript, медленно, но верно, захватывает JavaScript-мир. Этот тренд усилился. Создатели бесчисленного множества опенсорсных проектов спешат включить TypeScript в список поддерживаемых этими проектами возможностей. Например, Deno, проект, репозиторий которого на GitHub стал самым звёздным JS-проектом в 2020 году, имеет встроенный компилятор TypeScript.

В прошлом году я, учитывая всеобщий интерес к статической типизации и функциональному программированию, рекомендовал понаблюдать за PureScript, в котором всё это есть. Но в 2020 году этот проект, так сказать, не взлетел, на GitHub ему досталось всего 641 новая звезда, а интерес к нему упал на 3%. Если учесть огромный разрыв между TypeScript и его конкурентами, можно сказать, что война языков окончена, и что выиграла её разработка Microsoft. Любому новому проекту очень нелегко будет привлечь внимание сообщества после тех лет, которые оно провело в размышлениях и в атмосфере, перенасыщенной разновидностями JavaScript.

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

Фронтенд-разработка


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


Загрузки React в прошлом году

При оценке популярности UI-фреймворков применимы ещё два полезных показателя. Это теги в GitHub и вакансии. Сейчас на GitHub имеется более 80000 репозиториев с тегом React, а с тегом Vue 25000. Если же взглянуть на рынок труда, то окажется, что в прошлом мае ресурс Career Karma сообщал о том, что на Indeed.com имеется 10005 вакансий React-разработчиков в США и лишь 1025 вакансий для Vue-разработчиков. Библиотека React буквально вездесуща, она хорошо выдерживает натиск сильных конкурентов.

Я не могу завершить этот раздел, не упомянув о Svelte и Angular. Фреймворк Angular всё ещё весьма популярен в прошлом году он набрал 13,3 тысячи новых звёзд на GitHub, каждую неделю его загружали из NPM почти 2,5 миллиона раз. Для кого-то, учитывая популярность React, это может показаться неожиданным, но закрывать глаза на эти сведения нельзя. Если говорить о Svelte, то инструмент это, в сравнении с другими похожими, очень молод. Но он, в исследовании State of JS, занял первую строчку по показателю удовлетворённости разработчиков. Правда, я ожидаю, что в 2021 году его популярность будет расти умеренными темпами. Дело в том, что React- и Vue-разработчикам для перехода на Svelte приходится взбираться на довольно-таки крутую кривую обучения.

Бэкенд-разработка


Сфера разработки серверных частей веб-проектов сейчас устроена довольно сложно. Здесь фреймворки для генерирования статических сайтов соседствуют с проектами, рассчитанными на создание API. Если немного во всём этом разобраться и сосредоточиться лишь на фреймворках, рассчитанных исключительно на серверы, то окажется, что позиции Express с 51500 GitHub-звёзд всё ещё весьма крепки. Но в интересующую нас область стремительно ворвался фреймворк Nest, который, только за 2020 год набрал 10300 новых звёзд на GitHub. В результате общее количество звёзд этого фреймворка достигло 33,6 тысяч. Разработчики прибегают к этому фреймворку, привлечённые тем, что он выдвигает строгие требования к проектам, создаваемым на его основе. Это способно ускорить разработку и упростить обслуживание готовых проектов. И, кстати, Nest использует TypeScript.

Если принять во внимание процветание фуллстек-фреймворков, то окажется, что сейчас на наших глазах разворачивается очень важная битва за сердца и умы разработчиков. Дело в том, что такие фреймворки оказывают огромное влияние на архитектуру и производительность приложений, на то, как именно эти приложения работают. В настоящий момент два подобных фреймворка, основанных на React NextJS и Gatsby, значительно популярнее своих Vue-конкурентов, но это лишь подтверждает всё то, что нам известно об экосистеме инструментов для фронтенд-разработки. Внимания же заслуживает то, насколько упал рейтинг удовлетворённости разработчиков фреймворком Gatsby. Отдельные наблюдения указывают на то, что при работе с этим фреймворком программисты сталкиваются с неприятным опытом, хотя есть и сведения о том, что это не так. Учитывая то, что фреймворк NextJS разработан Vercel, и то, что его оснащают возможностями по генерированию статических сайтов, я могу говорить лишь о том, что в этом году его привлекательность будет расти.

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


В сфере инструментов для сборки проектов прямо сейчас видна острая конкурентная борьба. Несмотря на то, что разработчики жалуются на DevX Webpack, этот сборщик проектов, долгое время удерживавший пальму первенства в своей сфере, всё ещё занимает первое место среди конкурентов по объёму использования. В прошлом году можно было видеть, как в сферу сборщиков проектов пришёл Rome, в этом году к верхним строчкам отчётов проекта Rising Stars будут стремиться esbuild, Snowpack и Vite. Цель esbuild проста: ускорение процесса сборки проектов. Это, очевидно, весьма ценно для множества программистских команд и объясняет рост популярности данного инструмента.


Сборщики esbuild и Snowpack попали в верхние строчки соответствующего раздела исследования State of JS 2020

Одна из метрик популярности проектов это количество GitHub-звёзд. Но есть и другие показатели. Например, Snowpack стал первым в отчёте по технологиям, которые интересны разработчикам, и, что даже важнее, оказался в верхней части отчёта об удовлетворённости технологиями. Популярность Snowpack и Vite это недвусмысленное послание, говорящее нам о том, что сообщество серьёзно относится к нативным ES-модулям. Это крайне важная тема, так как выбор инструмента оказывает влияние на процесс сборки проектов, на кеширование, на соотношение модулей, используемых в разработке и в продакшн-окружении.

Инструменты для управления состоянием приложений


Существует ли UI-фреймворк, который можно назвать полным решением для разработки интерфейсов, не подключив к нему соответствующую библиотеку для управления состоянием приложений? Если не принимать во внимание споры о сопоставлении сложности решений с выгодностью их применения в расчёте на будущее, оказывается, что сфера управления состоянием приложений весьма интересна. Дело в том, что Redux испытывает давление с двух сторон: со стороны самой библиотеки React, и со стороны новых независимых разработок.

Я по собственному опыту знаю о мощи хуков React и API Context, но и у них есть свои ограничения. В любом случае, они, определённо, пользуются среди React-разработчиков большой популярностью, так как почти половина участников исследования State of Front End сообщила о том, что пользуется ими.


Раздел исследования State of Front End 2020, посвящённый инструментам для управления состоянием приложений

Итоги


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

Из данных 2020 года можно сделать один важный вывод: облик мира JavaScript-инструментов формируют крупные разработчики ПО. Так, TypeScript, разработка Microsoft, становится индустриальным стандартом, а у проектов, в которых используется этот язык, больше шансов добиться успеха. Хорошие примеры этого тренда NestJS и NextJS (которые не стоит путать).

На мир JavaScript оказывает влияние и JAMStack-подход к разработке проектов, и потребность в их высокой производительности. При этом растёт значимость генераторов статических сайтов и инструментов наподобие esbuild.

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

Чего вы ждёте от JavaScript-инструментов в 2021 году?

Подробнее..

Перевод 5 причин, по которым я люблю программировать в Linux

26.02.2021 12:14:08 | Автор: admin
Linux это отличная платформа для занятий программированием. На нашей стороне логичность, высокая эффективность, лёгкость работы с исходным кодом.

В 2021 году Linux выглядит как никогда привлекательно. Я собираюсь написать материалы, в которых расскажу о 21 способе использования Linux. А в этой статье я хочу поговорить о том, почему так много программистов выбирают Linux.

Когда я начал пользоваться Linux, я работал в сфере кинопроизводства. Я выбрал Linux из-за того, что эта ОС замечательно поддерживала работу с мультимедийными данными. Мы выяснили, что обычные коммерческие приложения для редактирования видео не способны обрабатывать большинство тех записей, которые мы извлекали из практически любых устройств, оснащённых камерами. Тогда я не знал о том, что Linux имеет репутацию операционной системы, рассчитанной на серверы и на программистов. Чем больше задач я решал с помощью Linux, тем сильнее мне хотелось научиться управлять всеми свойствами этой ОС. В итоге я выяснил, что компьютер показывает всю свою мощь тогда, когда его пользователь способен говорить на его языке. Через несколько лет после перехода на Linux я уже писал скрипты для автоматического редактирования видео, для объединения аудиофайлов, для пакетного редактирования фотографий, и для решения любых задач, которые мне удавалось сформулировать, и для которых удавалось найти решение. Мне не потребовалось много времени на то, чтобы понять, почему программисты любят Linux. Но именно Linux научила меня любить программирование.



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

1. Логичность Linux


Linux построена вокруг идеи автоматизации. Основные приложения Linux совершенно осознанно сделаны такими, чтобы их можно было бы, как минимум, запустить из терминала, указав дополнительные опции. А часто их можно и полностью использовать тоже из терминала. Эту идею иногда ошибочно считают чем-то вроде примитивной модели организации вычислений, так как существует распространённое (и неправильное) мнение о том, что писать программы, работающие из терминала, это значит прилагать абсолютный минимума усилий к тому, чтобы получить работающее приложение. Это печальный результат непонимания того, как работает программный код, но многие из нас периодически страдают таким вот непониманием. Мы думаем, что больше это всегда лучше, поэтому приложение, содержащее 1000 строк кода должно быть в 100 раз лучше, чем приложение, содержащее 10 строк кода. Так? Но правда заключается в том, что, при прочих равных условиях, лучше выбрать приложение, отличающееся большей гибкостью, при этом то, из скольких строк кода оно состоит, значения не имеет.

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

  1. Открыть PDF-файл в редакторе.
  2. Открыть файл с обложкой.
  3. Присоединить PDF-файл к файлу с обложкой.
  4. Сохранить полученный документ в виде нового PDF-файла.
  5. Повторить эти действия при обработке остальных старых файлов (а вот новые файлы, полученные из старых, обрабатывать уже не нужно).

Эта последовательность действий вполне согласуется со здравым смыслом, и хотя в ней много неприятных повторений, она позволяет достичь цели. В Linux, правда, можно организовать работу гораздо разумнее. Процесс размышлений над этой задачей, учитывающий возможности Linux, похож на процесс размышлений над ручным способом решения задачи. А именно, всё начинается с поиска последовательности действий, необходимых для получения нужного результата. Проведя некоторые изыскания, можно узнать о команде pdftk-java, а потом выйти на простое решение:

$ pdftk A=cover.pdf B=document_1.pdf \cat A B \output doc+cover_1.pdf

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

$ find ~/docs/ -name "*.pdf" | \parallel pdftk A=cover.pdf B={} \cat A B \output {.}.cover.pdf

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

2. Возможности по управлению связями кода


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

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

Это имеет отношение не только к Linux, но и к другим платформам. В Linux можно писать код, который планируется запускать и в Linux, и в других операционных системах. Понимание того, как именно компилируется код, помогает программисту в достижении его целей.

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

3. Удобство работы с существующим кодом


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

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

4. Прямой доступ к периферии


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

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

5. Хорошо продуманные абстракции


Linux, в то же время, даёт нам и разумный набор слоёв абстракции, применимых в ситуациях, когда прямой доступ к чему либо или ручное написание некоего кода может вылиться в больший объём работы, чем тот, к которому готов программист. Много удобных инструментов можно найти в Qt и Java, есть целые стеки вспомогательных технологий, вроде Pulse Audio, Pipewire и gstreamer. Linux стремится к тому, чтобы её пользователи могли бы заниматься программированием, и не скрывает этого.

Итоги


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

Какой ОС вы пользуетесь при написании программ?
Подробнее..

Перевод PowerShell это язык программирования?

27.02.2021 12:14:40 | Автор: admin
Является ли PowerShell языком программирования? Совершенно определённо является. И не обращайте внимание на тех, кто говорит, что это не так. Многие, работающие в сфере программирования, могут просто посмеяться над мыслью о том, что код, написанный для PowerShell это нечто большее, чем обычные скрипты. Такие люди категорически неправы. Здесь мы поговорим о том, почему это так. Но если вы читаете этот текст в поиске чёткого ответа, то знайте PowerShell это язык программирования. Более того, PowerShell это поразительный инструмент, который позволяет решать практически любые задачи. С помощью PowerShell можно сделать что-то простое, такое, что обычно делают в командной строке Windows (CMD), а можно, используя Windows Forms, построить полномасштабное приложение. Границы того, что можно создать с помощью PowerShell, ограничены лишь фантазией разработчика и его навыками поиска в интернете.



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

Зачем вообще учиться программировать?


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

Благодаря поисковику Google и видеохостингу YouTube (это, соответственно, первый и второй по посещаемости сайты в мире) в нашем распоряжении имеются нескончаемые запасы бесплатных и хорошо подготовленных учебных материалов. Если тому, кто хочет изучить некий язык программирования, попадётся хороший курс, то он меньше чем за час (в буквальном смысле) сможет настроить среду разработки и написать свой первый Hello World. На следующем рисунке можно видеть Hello World на PowerShell.


Hello World на PowerShell это очень просто

Может, изучая программирование, вы подумываете о продвижении по карьерной лестнице и считаете, что знания из сферы DevOps это как раз то, что вам нужно. Ведущие языки программирования для DevOps это Golang, Python, Ruby, C# Данный список можно продолжать и продолжать (и в этот список, пожалуй, можно включить практически все актуальные языки программирования).

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

Что такое язык программирования?


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

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

Существуют разные виды языков программирования. Кратко опишем их:

  • Процедурные языки программирования. В них код выполняется линейно и пошагово. Это означает, что если некто создал приложение, то код этого приложения должен выполниться от начала до конца, после чего его работа завершается. А если при выполнении этого кода возникнут какие-то проблемы его выполнение должно быть прервано.
  • Функциональные языки программирования. Тут используются символические представления вычислений. В таких языках применяются конструкции, которые не особенно сильно отличаются от математических функций.
  • Объектно-ориентированные языки программирования. В этих языках типы данных могут содержать как данные, в форме атрибутов и свойств объектов, так и функции, манипулирующие этими данными.
  • Скриптовые языки программирования. Для запуска кода, написанного на таких языках, не нужен компилятор. Они используют так называемые интерпретаторы. При написании программ на этих языках применяются предварительно подготовленные команды и функции, хотя подход к созданию программ на таких языках похож на подход, используемый при работе со стандартными языками.
  • Логические языки программирования. В логических языках программирования используются (вот уж неожиданность) правила логики. Они позволяют, оперируя фактами и заданными правилами, автоматически выводить результат.

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

Суть PowerShell


До PowerShell в мире Microsoft Windows существовал VBScript. Используя этот язык программирования можно решить очень большое количество задач, но в наше время, в 2021 году, вероятно, это количество примерно равно количеству задач, нерешаемых с помощью VBScript. Инструмент PowerShell создавался как средство, которое поможет использовать всё лучшее, что есть в платформе .NET, и при этом будет иметь доступ ко встроенным возможностям ОС. Джеффри Сновер, человек, который придумал PowerShell, на самом деле, очень подробно об этом рассказывает в работе Monad Manifesto, которую он написал в 2002 году. Это захватывающее чтение, в этом материале чётко выражено его видение проекта, который в итоге и стал тем, что получило название PowerShell.

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

И всё же, PowerShell это язык программирования или нет?


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

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

В PowerShell для организации обмена переменными и данными используются объекты. Поэтому можно сказать, что тут используются идеи, роднящие PowerShell с объектно-ориентированными языками программирования. Многие считают PowerShell скриптовым языком программирования. А это, что невозможно не признать, во многих отношениях так и есть. Но PowerShell-код может работать и как код обычных приложений. Этот код, как и программы, написанные на том же Python, или на ещё каком-то распространённом языке, может включать в себя циклы, вроде foreach и while, условные конструкции и многое другое.

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

Если говорить серьёзнее, то PowerShell может оказать компьютерщику огромную помощь, и речь идёт не только о решении рабочих задач. Например, я хочу написать цикл материалов о том, как я создал простое Windows Form-приложение для моей мамы, которой уже за 70. Это приложение позволяет ей переключать настройки почтового сервера в путешествиях (до того, как мир охватило то, что происходит сейчас) буквально несколькими щелчками мыши.

Я надеюсь, что этот небольшой проект вдохновит на создание чего-то похожего тех, кто никогда ничего такого делать не пытался, и что процесс создания своего проекта принесёт им много положительных эмоций. Поэтому, если вам это интересно, можете иногда заглядывать в список моих публикаций. А вот материал о том, как узнать версию PowerShell в Windows 10.

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

Итоги


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

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

Какие задачи вы решаете с помощью PowerShell?

Подробнее..

Перевод Как освоить Vim?

05.03.2021 12:10:54 | Автор: admin
Осваивать Vim это, пожалуй, страшно. Или, точнее, очень страшно. Речь идёт об изучении совершенно необычного подхода к редактированию кода, не говоря уже о работе с простым текстом. Многие несправедливо обвиняют, тех, кто выбирает Vim, в том, что они впустую тратят время.

Я со всей уверенностью могу заявить о том, что Vim позволил мне повысить эффективность в деле написания программ. Работать стало удобнее (ниже я расскажу об этом более подробно). Я никому не хочу навязывать Vim, но очень рекомендую освоить этот редактор всем, кто занимается программированием, работает в сфере Data Science, в общем тем, кто так или иначе пишет и редактирует некий код.



Если вам очень хочется узнать о том, стоит ли вам использовать Vim, и о том, кто и для чего им реально пользуется взгляните на этот материал (кстати, не позвольте его названию, Не пользуйтесь Vim, ввести себя в заблуждение). Ещё можете посмотреть это видео, которое, кстати, подготовил сам Люк Смит.

А теперь, учитывая всё вышесказанное, предлагаю поговорить о том, что такое, на самом деле, Vim!

Что такое Vim?


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

В Vim имеется несколько режимов работы, переключение между ними приводит к изменению функционала клавиатурных клавиш (например, клавиша W в режиме вставки, что неудивительно, позволяет ввести букву w, а вот в нормальном режиме она позволяет перемещать курсор вперёд на одно слово). При таком подходе клавиатура используется и для ввода символов, и для перемещения по тексту. Другими словами при работе в Vim не нужна мышь.

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

Конечно, на то, чтобы привыкнуть к Vim, нужно некоторое время. И это не прямая замена какой-нибудь IDE или редактора вроде VS Code. Но можно сказать, что Vim позволяет тому, кто умеет им пользоваться, значительно ускорить работу с кодом. Кроме того, интересно то, что его более простым аналогом является Vi стандартный текстовый редактор большинства Unix-подобных систем, работающий в терминале.

Как научиться работать в Vim?


1. Используйте vimtutor


Меня не удивляет то, что в каждом руководстве по Vim рекомендуется начинать изучать этот текстовый редактор с vimtutor. Поэтому я, без зазрения совести, поступлю так же. Нет нужды играть ни в какие Vim-игры (хотя они и довольно интересны), или прибегать к программам, помогающим запоминать бесчисленные клавиатурные сокращения. Надо просто установить vimtutor и, когда найдётся 10-15 минут свободного времени, прорабатывать этот официальный учебник по Vim. И не пытайтесь сразу же запомнить все клавиатурные сокращения Vim; вы запомните их постепенно, снова и снова проходя уроки vimtutor.

Хочу отметить, что Windows-пользователям я рекомендую использовать WSL (Windows Subsystem for Linux, подсистему Windows для Linux) и для прохождения vimtutor, и, в целом, для работы с Vim. Лично я в Windows с Vim не работал, поэтому не могу обещать того, что при работе с ним в этой ОС всё будет точно так же, как в Linux.

2. Постоянно пользуйтесь Vim


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

Используйте Vim как можно чаще. Нужно просмотреть текстовый файл? Запустите Vim. Хотите что-то по-быстрому изменить в Python-скрипте? Примените Vim. Делаете какие-то заметки? Делайте их с помощью Vim. В общем, полагаю, вы меня поняли. И каждый раз, когда работаете в Vim, всегда задавайтесь вопросом о том, какова наиболее эффективная последовательность нажатий на клавиши (то есть наиболее короткая последовательность), позволяющая решить текущую задачу.

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

3. Интегрируйте с Vim всё что сможете


Используйте клавиатурные привязки Vim везде, где это возможно. Начните делать всё, что сможете, в стиле Vim. Например, если вы пользуетесь браузером, основанным на Chromium (Chrome, Brave, Edge), или браузером Firefox, подумайте об установке расширения Vimium, которое позволяет пользоваться в браузере клавиатурными сокращениями Vim, отвечающими за перемещение по документу (H, J, K, L и так далее).

Если вы пользуетесь для работы с кодом некоей IDE найдите плагин или расширение для добавления Vim-привязок в соответствующую среду. Например, пользователи PyCharm (или любой IDE от JetBrains) могут воспользоваться ideavim. А пользователи VS Code (в 2021 году этот инструмент уже ближе к IDE, чем к обычным текстовым редакторам) могут прибегнуть к расширению VSCodeVim.

В Jupyterlab можно включить привязки Vim для встроенного текстового редактора путём установки jupyterlab-vim, что позволит полностью эмулировать Vim в ячейках блокнотов.

Постарайтесь органично интегрировать Vim в свою рабочую среду и несколько недель поработайте по-новому. Я могу говорить о том, что после нескольких VSCode-сессий в стиле Vim мне стало гораздо удобнее пользоваться этим редактором. А ещё я очень рад избавлению от мыши!

4. Перенастройте клавишу Caps Lock (но это необязательно)


Самая бесполезная клавиша, расположенная в самом лучшем месте клавиатуры. Именно так можно охарактеризовать клавишу Caps Lock. Поэтому советую превратить Caps Lock в Escape. Если вы интересуетесь Vim, то уже должны знать о том, что клавиша Escape используется в Vim для переключения режимов. Я очень советую тем, кто стремится к максимальной эффективности, воспользоваться вышеописанной модификацией.

Пользователи Windows и WSL могут использовать uncap программу, которая превращает клавишу Caps Lock в Escape.

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

Если вы работаете в Linux настроить всё как надо вам помогут StackOverflow и Google. Лично я (заслуженный пользователь Arch Linux) использую утилиту setxkbmap, с помощью которой делаю из Caps Lock ещё одну клавишу Escape. А потом включаю автозапуск утилиты при запуске системы:

setxkbmap -option caps:escape

5. Глубже изучите Vim


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

  • ZZ сохранить документ и выйти из Vim. Красивая команда.
  • zz, zt, zb прокрутка текста, перемещающая строку с курсором, соответственно, в центральную, в верхнюю или в нижнюю часть области просмотра.
  • Ctrl+u, Ctrl+d прокрутка области просмотра вверх или вниз на полстраницы.
  • ciw (Change Inside Word) удаление текущего слова и автоматический переход в режим вставки.
  • C удалить текст от позиции курсора до конца строки и перейти в режим вставки.
  • dt<char> (Delete To <character>) удалить текст от позиции курсора до следующего вхождения указанного символа.
  • ~ (тильда, на стандартной клавиатуре вводится клавишей, находящейся под Escape) переключение регистра (верхний/нижний) текущего или выделенного символа.
  • . (точка) повтор последней команды Vim.
  • ggvG= (перейти в начало файла, войти в визуальный режим, выделить весь текст до конца, выровнять выделенные строки) автоматическое выравнивание текста во всём файле.

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

Если вас интересуют другие команды Vim посмотрите это замечательное и довольно длительное видео, демонстрирующее прохождение уроков vimtutor, которое записал Вим Дизель (шучу это всё тот же Люк). Тут собрано множество полезнейших советов по Vim.

Итоги


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

  • Можно установить Neovim и поэкспериментировать с ним (это отрефакторенный форк Vim, рассчитанный на высокий уровень расширяемости и на поддержку графического интерфейса).
  • Можно перенести функционал Vim в терминал или интерпретатор командной строки, воспользовавшись vim-airline.


Vim-airline, тема violet (источник)

  • Можно попробовать некоторые из популярных Vim-плагинов.

Желаю всем, кто дочитал до этого места, наслаждаться будущим, наполненным благами Vim (и освободиться от власти мыши или трекпада).

Пользуетесь ли вы Vim?

Подробнее..

Один день из жизни разработчика VMware

20.02.2021 12:17:51 | Автор: admin

В Москве семь часов вечера. Рабочий день подошел к концу. Коллеги прощаются, закрывают лэптопы и выходят из Zoomа. Город потихоньку засыпает, просыпаются айтишники. 19:00 по Москве это 08:00 в Сан-Франциско. Моя подруга из VMware Маша Шалдыбина делает утренний кофе, логинится и впрочем, обо всем по порядку.

Привет, Хабр. Меня зовут Катя Юдина, я руководитель контент-маркетинга облачного бизнеса МТС. Буквально на днях я взяла небольшое интервью у своей давней подруги, которая сейчас работает в центральном офисе хоум-офисе компании VMware. Под катом вас ждет интересный рассказ о карьере ИТ-специалиста в крупной международной компании. Поговорим о том, как происходит трудоустройство на западе, как устроена работа в VMware и почему мировой карантин почти никак не затронул отдел разработки.

Кстати, у нас отличная новость! Если у вас нет времени на чтение, можно прослушать подкаст-версию статьи по этой ссылке.


Маша, как начался твой путь в ИТ?

Скорее, не как, а когда в раннем детстве. Повлияла семья: оба родителя у меня физики. Так что у нас дома постоянно была разная электроника, даже компьютеры (что на тот момент было большой редкостью). Я достаточно рано освоила Бейсик. Помню, устраивала себе развлечение: писала программы, которые рисовали разные картинки на экране. Уже в школе заинтересовалась онлайн-играми, они как раз тогда только-только пошли. Когда я училась в 10 классе, была очень популярна Ragnark Online. Игрушка меня заинтересовала, но сам геймплей показался неторопливым. Нужно было постоянно фармить и ждать. Так что я развернула свою собственную версию и начала копаться в ее коде, чтобы настроить игру под свои хотелки.

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

Ты помнишь свое первое место работы?

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

Еще в ВУЗе я познакомилась с будущим мужем, Олегом. Дальше мы двигались вместе. Стало понятно: если мы хотим добиться большего, понадобится переезжать. Из Ташкента мы отправились в Санкт-Петербург. Там мы продолжили карьеру веб-разработчиков: я в Daxx, а Олег в Murano.

Тем не менее, мы все время находились в поисках лучшего. Через какое-то время муж прошел интервью в Microsoft, и его пригласили на работу в парижский офис. Но судьба распорядилась иначе. У компании, в которой он тогда работал, было много клиентов из США. Когда одному из них стало известно, что муж увольняется, он предложил ему дальше работать напрямую. Почему бы и нет?

Дальше началась маета с визами. После первого интервью в посольстве США на J-визу мы получили отказ. Пришлось штурмовать Америку заново. Наученные горьким опытом и добрым послом, мы подготовили новый пакет документов и подали на визу H1B. Шел 2008-й, год финансового кризиса, даже лотерея тогда не проводилась из-за недобора запросов (если в первый день подачи документов на визу, первого апреля, не набирается 65000 запросов, лотерею не проводят).

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

Эти же документы мы взяли с собой в Америку. Таможенник на границе проявил компетентность и долго расспрашивал нас про этот сайт. Нам показалось даже, что он украдкой зашел на него во время беседы. Когда очередь дошла до меня, я сказала, что работать не планирую виза не позволяет. Таможенника этот ответ устроил, и мы, наконец, услышали заветное: Welcome to the United States.

Ты сразу пошла на работу в VMware?

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

Самый главный документ США, SSN (номер социального страхования, который присваивается всем гражданам и резидентам США), мы оформили быстро и без проблем. Всю информацию в доступной форме можно найти на сайтах агентств.

Разумеется, сложа руки я не сидела. Постоянно решала задачи на всяких Topcoderах и CodeSprintах, готовилась к интервью. Есть такая хорошая книга Cracking the Coding Interview. В ней описано, как проходить собеседования в крупных ИТ-компаниях, таких как Google или Facebook. Много хороших задач с решениями, рекомендую. Еще я прошла сертификацию на знание языков программирования, создала приложение для iPhone то есть, всеми силами старалась сформировать хорошую базу для устройства на работу.

Cracking the Coding Interview

Когда через год я получила разрешение на работу, началась фаза активных поисков компании мечты. У меня были друзья в Facebook с их помощью удалось получить приглашение на интервью. Здесь важно понимать: в Америке как нигде сильно понятие leverage потенциальный работодатель может заинтересоваться тобой, если ты упомянешь о собеседовании в другой компании того же ранга. Так что интервью в Facebook мне помогло получить приглашение от VMware. Они устроили все очень быстро, предложили даже пропустить телефонный этап и сразу пригласили on-site в офис. Дальше все достаточно стандартно: мне дали несколько задач, после решения я лично поговорила с руководителями и получила оффер. Собственно, так я и попала в VMware.

Расскажи подробнее об интервью. Что требуется, какой бэкграунд нужен кандидатам? Как проходит собеседование в деталях?

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

Может быть беседа с HR спрашивают про карьеру, цели, почему именно к нам?. Еще одна интересная разновидность интервью на дизайн. Писать код уже не придется вам зададут некий общий вопрос из серии как бы вы построили подобное приложение? и попросят обосновать свой выбор.

А что после собеседования? Сразу в поле или есть какая-то адаптация?

На самом деле, ввод новых сотрудников в эксплуатацию у нас поставлен очень грамотно, что называется на потоке. Первые пару недель занимают групповые тренинги и лекции. Тебя знакомят с компанией, ее целями, продуктами и историей. Затем прикрепляют к конкретной команде разработчиков и дают менеджера. Задания выдают попроще. В VMware для учета багов и фич используется Pivotal Tracker весьма удобный инструмент, а для команд менее 5 человек он доступен бесплатно. Обычно раз в неделю обсуждается, кто из сотрудников над какой задачей будет работать. Вливание в работу очень мягкое и спокойное. Все хорошо документировано, так что типовых проблем надо срочно что-то делать, но непонятно как не возникает.

Pivotal Tracker

Когда я присоединилась к VMware, мне поручили работу в проекте Cloud Foundry. На тот момент он существовал всего год. В двух словах, Cloud Foundry это система, которая позволяет разработчикам запускать свои приложения в облаке. Лично я работала над компонентами, отвечающими за корректную работу приложений, написанных на Node.js, он тогда как раз был на пике популярности.

Интересный момент как известно, основная деятельность VMware долгие годы была сосредоточена на решении достаточно низкоуровневых задач, близко к железу. А Cloud Foundry это уже software-level, он выбивался из концепции. Поэтому все высокоуровневые проекты решено было объединить в компанию Pivotal. То есть фактически это родная сестра VMware, обе находились в собственности Dell.

Таким образом, я перешла из VMware в Pivotal. Кто-то из моих коллег был против перехода, они остались в VMware, ушли на другие проекты. Дело было в экстремальном agile-подходе к написанию кода, принятом в Pivotal. Парное программирование, SCRUM-собрания. Мне это показалось интересной возможностью научиться чему-то новому, да и с людьми мне общаться легко. Почему бы и нет?

Так началась моя карьера в Pivotal. Спустя семь лет после начала моей работы компанию купила VMware, и я вернулась туда, откуда начинала (смеется).

На самом деле, все оказалось не так страшно. Сессии парного программирования устраиваются ежедневно с 9 утра до 6 часов вечера. Все очень хорошо организовано: на утреннем стендапе мы определяемся с пулом задач и выбираем себе пару. Садимся за один компьютер, работаем над одним и тем же кодом, но при этом у каждого свои монитор, клавиатура и мышь. Практика парного программирования обычно подразумевает, что один из нас драйвер, ведущий, а второй ведомый. Роли распределяются так: драйвер печатает код, фолловер проверяет и смотрит наперед, какие ошибки могут возникнуть в его работе. Идет постоянное обсуждение, как можно улучшить то или иное решение. Это очень помогает решать сложные задачи как известно, одна голова хорошо, а две лучше. Для продуктивности роли внутри пары меняются, обычно в середине дня. Кстати, у нас есть инстаграм, там можно посмотреть, как выглядят наши рабочие будни и праздники.

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

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

А как вы уходили на карантин? Были сложности с построением коммуникации с удаленным партнером по программированию?

Мы начали переход на удаленный режим работы еще до карантина. У нас было много офисов в Нью-Йорке, Лондоне, Мюнхене. Иногда члены одной команды могли жить в разных городах. Да мы и ранее занимались парным программированием удаленно. Например, в моей команде были ребята из Нью-Йорка. Утром мы все встречались в Zoom, обсуждали дела и разделялись на пары. Собственно, на карантине все происходит точно так же. Ведущий включает демонстрацию экрана, ведомый может делать аннотации и по необходимости перехватывает управление. С кодом работаем в основном в Visual Studio Code. При необходимости разворачиваем виртуальную машину и работаем на ней. В этом сценарии для совместной работы в терминале используем Tmux, а код пишем в Vim. Мы привыкли к такому формату, так что карантин не стал для нас шоком.

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

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

В двух словах: над какими продуктами ты работала/работаешь?

Над Tanzu Application Service. Я участвовала практически во всех командах разработки: различные бэкенд-подсистемы, фронтенд, интерфейс командной строки, непрерывная интеграция и релиз. Примерно раз в год в проекте происходит ротация, и команды перетасовываются. Это не только предотвращает выгорание, так как не приходится годами долбить одно и то же, но и не порождает новых проблем, что тоже важно. Наоборот, свежий взгляд на код помогает делать его лучше и чище.

Маша, спасибо! Надеюсь, следующий раз получится рассказать об одном дне из жизни разработчика Google :)

***

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

Подробнее..

5 подходов к стилизации React-компонентов на примере одного приложения

16.02.2021 12:20:24 | Автор: admin


Доброго времени суток, друзья!

Сегодня я хочу поговорить с вами о стилизации в React.

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

Когда дело касается разметки (HTML), то React предоставляет в наше распоряжение JSX (JavaScript и XML). JSX позволяет писать разметку в JS-файлах данную технику можно назвать HTML-в-JS.

Однако, когда речь идет о стилях, то React не предоставляет каких-либо специальных инструментов (JSC?). Поэтому каждый разработчик волен выбирать такие инструменты по своему вкусу.

Всего можно выделить 5 подходов к стилизации React-компонентов:

  • Глобальные стили все стили содержатся в одном файле (например, index.css)
  • Нативные CSS-модули для каждого компонента создается отдельный файл со стилями (например, в директории css); затем эти файлы импортируются в главный CSS-файл (тот же index.css) с помощью директивы "@import"
  • Реактивные CSS-модули (данная техника используется не только в React-проектах; реактивными я назвал их потому, что библиотека css-modules в настоящее время интегрирована в React, т.е. не требует отдельной установки, по крайней мере, при использовании create-react-app) для каждого компонента создается файл Component.module.css, где Component название соответствующего компонента (обычно, такой файл размещается рядом с компонентом); затем стили импортируются в JS-файл в виде объекта, свойства которого соответствуют селекторам класса (например: import styles from './Button.module.css'; <button style={styles.button}>Нажми на меня</button>)
  • Встроенные (инлайновые) стили элементы стилизуются с помощью атрибутов style со значениями в виде объектов со стилями (например, <button style={{ borderRadius: '6px'; } }>Нажми на меня</button>)
  • CSS-в-JS библиотеки, позволяющие писать CSS в JS-файлах; одной из таких библиотек является styled-components: import styled from 'styled-components'; const Button = styled`какой-то css`; <Button>Нажми на меня</Button>

На мой взгляд, лучшим решением является последний подход, т.е. CSS-в-JS. Он выглядит самым логичным с точки зрения описания структуры (разметки), внешнего вида (стилей) и логики (скрипта) компонента в одном файле получаем нечто вроде Все-в-JS.

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

Ну, а худшим подходом, по моему мнению, являются встроенные стили. Стоит, однако, отметить, что определение объектов со стилями перед определением компонента и последующее использование этих объектов напоминает CSS-в-JS, но остаются camelCase-стиль, атрибуты style и сами встроенные стили, которые затрудняют инспектирование DOM.

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

Исходный код GitHub.

Песочница:


Выглядит приложение так:



Приложение состоит из трех компонентов: Title заголовок, Counter значение счетчика и информация о том, каким является число: положительным или отрицательным, четным или нечетным, Control панель управления, позволяющая увеличивать, уменьшать и сбрасывать значение счетчика.

Структура проекта следующая:

|--public  |--index.html|--src  |--components    |--Control      |--Control.js      |--Control.module.css      |--package.json      |--styles.js    |--Counter      |--Counter.js      |--Control.module.css      |--package.json      |--styles.js    |--Title      |--Title.js      |--Title.module.css      |--package.json    |--index.js  |--css    |--control.css    |--counter.css    |--title.css  |--App.js  |--global.css  |--index.js  |--nativeModules.css  |--reactModules.css...

Пройдемся по некоторым файлам, находящимся в директории src:

  • index.js входная точка JavaScript (в терминологии бандлеров), где импортируются глобальные стили и рендерится компонент App
  • App.js основной компонент, где импортируются и объединяются компоненты Control, Counter и Title
  • global.css глобальные стили, т.е. стили всех компонентов в одном файле
  • nativeModules.css файл, где импортируются и объединяются нативные CSS-модули из директории css (control.css, counter.css и title.css)
  • reactModules.css глобальные стили для реактивных CSS-модулей
  • components/Control/Control.js три реализации компонента Control (с глобальными стилями/нативными CSS-модулями, c реактивными CSS-модулями и стилизованными компонентами), а также пример объекта со встроенными стилями
  • components/Control/Control.module.css реактивный CSS-модуль для компонента Control
  • components/Control/styles.js стилизованные компоненты для компонента Control (когда стилизованных компонентов много, я предпочитаю выносить их в отдельный файл)
  • components/Control/package.json файл с main: "./Control", облегчающий импорт компонента (вместо import Control from './Control/Control' можно использовать import Control from './Control'
  • components/index.js повторный экспорт, позволяющий разом импортировать все компоненты в App.js

Как всегда, буду рад любой форме обратной связи.

Благодарю за внимание и хорошего дня.
Подробнее..

Внедрение E2E-тестирования с Puppeteer и Jest

18.02.2021 10:20:32 | Автор: admin

Привет, Хабр!

Хотим поделиться краткой историей о том, как мы на одном из проектов Рексофт пришли к написанию автотестов, и почему сделали акцент именно на e2e-тестах.

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

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

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

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

В качестве базового фреймворка для тестов был выбран Jest, а для имитации действий пользователя Puppeteer. Последний выбрали благодаря тому, что он поддерживается Google и имеет отличную документацию. Нам было вполне достаточно тестов в одном браузере (Chrome) (хотя, есть инструменты, позволяющие с помощью Puppeteer запускать тесты и в других браузерах, например, Firefox и IE). Playwright тогда ещё не было, а Selenium, чисто субъективно, казался более сложным в развертывании.

Далее кратко опишу преимущества и недостатки e2e-тестов.

Недостатки e2e-тестов

Относительно высокая сложность написания. Нужно обладать определёнными навыками, чтобы написать компактный и легкочитаемый e2e-тест.

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

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

Хрупкость e2e-тестов. Что я имею ввиду? Случай, когда тест падает без видимых на то причин, а при повторном запуске успешно выполняется, или же когда к падению теста приводит незначительное изменение в верстке. С хрупкостью тестов можно бороться с помощью автоматического перезапуска теста после падения. Помогут в этом раннер jest-circus и параметр retryTimes. Это практически полностью решает проблему ложных падений тестов.

Преимущества e2e-тестов

Гарантии. С e2e-тестами вы получаете определенные гарантии того, что система в целом работает корректно. Юниты такой гарантии не дают. Разумеется, это не значит, что вы получаете 100% гарантию того, что у вас работает абсолютно всё. Но вы будете уверены, что по крайней мере протестированные сценарии точно работают.

Снижение рабочей нагрузки. Без тестов разработчик вынужден думать как бы чего не сломать. Ведь не прокликивать же весь проект после очередного коммита с правками! С тестами вы узнаете о поломке еще до того, как код будет залит на стенд.

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

Ускорение рефакторинга. При рефакторинге js, e2e-тесты не придется переписывать. Да и рефакторинг в вёрстке тоже редко приводит к их переписыванию.

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

Лайфхаки

1. Для ускорения написания первых тестов можно записывать действия пользователя с помощью Headless recorder или с помощью встроенных в Chrome инструментов.

2. Если требуется проверить несколько наборов данных в рамках одного кейса и руки тянутся написать for внутри теста, используйте jest-each. Эта библиотека позволит прогнать несколько наборов данных в одном кейсе, сохранив читаемость кода:

each` url | selector | expectedIsVisible ${'/page1.html?land'} | ${'.js-order-button'} | ${true} ${'/page1.html'} | ${'.js-order-button'} | ${false} ${'/page2.html?land'} | ${'.js-order-button'} | ${true} ${'/page2.html'} | ${'.js-order-button'} | ${false}`.it('Отображение кнопок заказа на странице $url', async ({ url, selector, expectedIsVisible }) => { await page.goto(`${SERVER_URL}${url}`, {   waitUntil: 'networkidle2',   timeout: 0 }); expect(await isVisible(page, selector)).toEqual(expectedIsVisible);});

3. В случае возникновения ошибок, puppeteer не всегда корректно подсвечивает строку с ошибкой. Поэтому следует проверить код перед ошибочной строкой, часто ошибка кроется именно там.

4. Puppeteer позволяет запускать браузер с различными флагами, что иногда очень полезно (chrome://flags/). Ниже пример запуска браузера с отключенным флагом SameSite by default cookies

puppeteer.launch({ headless: true, slowMo: 80, args: [   '--disable-features=SameSiteByDefaultCookies' ]});

В качестве заключения

Написание e2e-тестов занимают около 5-10% от времени написания фичи. На фиксы багов уходило сильно больше времени, так что оно того стоило. Несмотря на ряд недостатков, e2e-тесты позволяют значительно ускорить процесс разработки и обрести уверенность в том, что основная функциональность системы работает.

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

Подробнее..

Pet-проект для джуна. Или зачем и как выбрать pet project. (личный опыт)

23.02.2021 14:15:47 | Автор: admin

Предисловие

Привет Хабр! Эта публикация написана джуном для джунов (но возможно и специалисты более высокого уровня что-то найдут для себя / своих падаванов).

Зачем нужны pet проекты?

Для саморазвития как разработчика и закрепления изученного материала.

Если Вы днями на пролёт "штурмуете" теорию: читаете посты, смотрите туториалы, но при этом не применяете изученное на практике, то времени на освоение выбранной Вами темы понадобится в разы больше.

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

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

Суммируя pet проекты нам нужны для:

  • изучения / закрепления нового материала;

  • получения удовольствия от разработки чего-то интересного лично Вам;

  • пополнения своего портфолио;

  • (bonus) есть шанс что Ваш pet проект может кому-то приглянуться и тогда из этого можно получить финансовую выгоду.

Как выбрать и на что обратить внимание?

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

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

Технологии

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

Дизайн

Тут все зависит от человека и ситуации. Есть два варианта:

  1. Запариться и сделать крутейший дизайн.

    Плюсы:

    • lvl up как дизайнера;

    • обычно свой дизайн очень приятен;

    • так как это собственный макет Вы в нём хорошо ориентируетесь и ещё на этапе дизайна продумываете некоторые фичи.

    Минусы:

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

  2. Найти готовый дизайн и работать с ним.

    Плюсы:

    • быстро (хотя поиск может затянуться, об этом ниже);

    • не нужно отвлекаться на дизайн.

    Минусы:

    • не всегда можно найти дизайн для Вашей задумки, особенно если она не типичная;

    • готовые бесплатные макеты не всегда красивые.

Идея

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

Вот пару вечно актуальных примеров:

  • список задач;

  • список задач;

  • менеджер покупок;

  • сайт портфолио;

  • кино сайт;

  • калькулятор;

  • блог;

  • магазин чего-либо.

Личный опыт

В этом блоке я раcскажу как придумывались / создавались мои pet проекты.

Начало (AniList)

Шёл июль 2020 года. Спустя семестр изучения JavaScript'а в колледже я решил изучить какой-то фреймворк. Выбор пал на React. Через пару дней ознакомления с фреймворком я наткнулся на серию видеороликов по разработке веб-приложения пиццерии на ютуб канале Archakov Blog. И решил сразу же применять изученное в видео на реальном проекте, но просто переписывать код из видео в IDE было не интересно. По этому я решил делать аниме список.

Выше я писал про два варианта получения дизайна для проекта. Какой же из вариантов выбрал я при создании макета? Оба. Для начала я зашёл на уже существующие сайты с такой-же тематикой потом пролистал Behance и собрал своего "франкенштейна" из собственных идей и кусков уже готовых дизайнов.

Скриншот проекта из FigmaСкриншот проекта из Figma

По готовому макету я понял что мне нужно будет где-то брать информацию об аниме (API, AJAX), где-то хранить её (Redux), а также как-то организовать авторизацию и хранение информации о пользователях (Firebase) + работа с версиями файлов(GIT, GitHub). В итоге мне предстояло ознакомиться как минимум с 5 новыми технологиями помимо React.

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

ToDo list

Дизайн ToDo appДизайн ToDo app

Следующим проектом должен был стать todo list. Мой одногруппник (тоже начинающий фронтендер) должен был делать frontend на Angular, а я (неожиданно) backend. Тут мне пристояло погрузиться в мир backend'а и может не изучить, но хорошо так ознакомиться с NodeJS, Express, MongoDB, mongoose, cors, dotenv, способами авторизации, деплоем на Heroku и ещё глубже понять работу API.

По итогу вышло так что и я и мой товарищ каждый для себя писали back и front end.

Остальное

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

Приложение погоды:

  • рисование на canvas'е;

  • работа с геолокацией;

  • анимация React компонентов.

Shedaily (front & back end) - приложение которое парсило расписание из сайта колледжа где я учусь и приводило его в приятный вид:

  • парсинг информации из сайта;

  • работа с Excel таблицами в NodeJS.

Terminal website - вдохновившись сайтом dodo.dev создал сайт с контактами:

  • SCSS;

  • Gulp.

Менеджер подписок:

  • MobX;

  • переключение темы.

Магазин аксесcуаров (backend) (в разработке):

  • более глубоко познал MongoDB + mongoose;

  • GraphQL.

Портфолио (на стадии дизайна):

  • JAM stack;

  • Gatsby;

  • создание кастомного курсора.

Заключение

Недавно меня постигла идея переписать свой первый pet project (Аниме список), но теперь с новыми навыками: backend на NodeJS, Express, GraphQl вместо Firebase, и frontend React + Apollo Client, ну и дизайн по красивше сделать. Эта мысль является результатом моего прогресcа который я постиг благодаря pet проектам.

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

Подробнее..

Перспективы разработчика в автоматизации тестирования ПО

15.02.2021 10:17:19 | Автор: admin

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

Лирическое отступление

Это только присказка, сказка впереди

В начале 2000-x я работал в IT-компании, которая выполняла несколько аутсорсинговых проектов для компании Integrated Genomics. Проекты были связаны с расшифровкой геномов простейших организмов. К примеру, одна из утилит искала фрагменты (праймеры) с определенными свойствами в геноме кишечной палочки. На входе утилиты была последовательность ДНК, загружаемая из публичной базы геномов ERGO и состоящая из азотистых оснований. На выходе таблица фрагментов и их позиция в цепочке ДНК. Далее эти фрагменты использовались биологами для синтеза геномов. Задача была сравнительно простой. Нужно было лишь позаботиться о том, чтобы программа не выжирала всю оперативную память довольно слабых машин, которые были у нас на тот момент. Сложность других проектов заключалась в том, что они находились на стыке трех дисциплин: биологии, математики и информатики. В тех случаях, когда алгоритм задачи был понятен, его реализация в программном коде не представляла трудности. Но когда сама задача была неопределенной, и не находилось никого кто мог бы ее формализовать, это был серьезный вызов.

Выяснилось, что для того, чтобы успешно решать такие задачи, нужны фундаментальные знания по биологии и высшей математике. Нас, молодых и горячих, это не остановило. Мы нашли англоязычную книгу по биоинформатике профессора Павла Певзнера и приступили к изучению. Поначалу повествование было легким и непринужденным. Во вступлении Павел рассказывал о том, как выживал в Москве в студенческие годы, и это было поистине приятное и расслабляющее чтение. Далее в первых главах речь шла про азотистые основания нуклеотидов ДНК аденин, гуанин, тимин и цитозин и про комплиментарность нуклеиновых кислот, а именно: как основания нуклеотидов способны формировать парные комплексы аденинтимин и гуанинцитозин при взаимодействии цепей нуклеиновых кислот. Было понятно, что такое свойство нуклеотидов играет ключевую роль в репликации ДНК. Я помню, что испытывал подъем и состояние потока, читая это объяснение, и мысленно представлял, как мы сейчас быстренько все это освоим (подумаешь, биология) и сможем брать более серьезные задачи. Мы даже думали о том, что сможем написать свой геномный ассемблер и взяться за расшифровку простейших геномов. Продолжаю читать книгу, и тут бах система уравнений на полстраницы без каких-либо объяснений. Из контекста подразумевалось, что эта система проще пареной репы, и любое объяснение будет оскорблением для читателя. Не было даже сноски для факультативного чтения. Я решил эту страницу пропустить, вернуться к ней позже и пока что продолжить читать дальше вдруг станет понятно. Перелистываю страницу а там еще одна система уравнений уже на всю страницу и скупое описание, часть слов из которого мы не нашли в словаре. Стало понятно, что эту область знаний на стыке геномики и математики нахрапом не возьмешь. Также стало понятно, почему подавляющее большинство коллег, с которыми мы взаимодействовали, имели биологическое и/или математическое образование. В конечном итоге, шаг за шагом погружаясь в основы геномики, нам удалось создать несколько программных продуктов, и тогда я в первый раз всерьез задумался о том насколько результативной и интересной может быть деятельность на стыке нескольких дисциплин.

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

Перспективы разработчика в автоматизации тестирования ПО

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

Исторически сложилось так, что в автоматизацию приходят специалисты с опытом в ручном тестировании ПО. В какой-то момент они осознают, что рутинные операции можно и нужно автоматизировать, либо просто желают попробовать себя в новом качестве. Опыт, привносимый ручными тестировщиками в проект автоматизации, бывает архиполезным. Никто лучше них не знает возможности и слабые места продукта, наиболее трудоемкие сценарии для тестирования, окружение, в котором работает продукт, а также пожелания пользователей и планы на следующие релизы. Как правило, хороший ручной тестировщик четко понимает, что именно он хочет автоматизировать, но с написанием автотестов порой возникают сложности. Почему? Потому что автотесты это такой же программный продукт, как и продукт, который они призваны тестировать. Нужно продумать архитектуру системы автотестов, механизмы их запуска (Continuous Integration, CI) и самое главное нужно писать хороший код. По факту, для ручного тестировщика это зачастую оказывается непросто. Ведь здесь требуется создать полноценный проект, который можно интегрировать в CI, изменять, расширять и переиспользовать. Для этого нужны способности к программированию, накопленный опыт и набитые шишки.

Ручной тестировщик с глубоким пониманием продукта и методик тестирования и разработчик с опытом программирования отлично дополняют друг друга. Первый силен в постановке задачи (use case -> test case), второй в ее реализации. Встает вопрос: почему среди автоматизаторов встречается много ручных тестировщиков? На это есть несколько причин:

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

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

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

Опасение потерять в карьерном росте и зарплате.

Разберем эти моменты.

Автотесты это такой же продукт разработки, как и тот продукт, для которого эти автотесты создаются. Если разработчик идет на позицию автоматизатора в выделенную группу разработки автотестов, он остается на стезе написания программного кода. Да, ему надо иметь представление о тестировании ПО, но базовые знания можно сравнительно быстро получить, пролистав какое-либо руководство по тестированию ПО (например, вот эту книгу). Безусловно, автоматизатору нужно понимать продукт, для которого он пишет автотесты. Но освоить продукт на приемлемом уровне зачастую оказывается легче, чем научиться писать хороший код. Знания о продукте и методиках тестирования будут расширяться по мере ознакомления с багами, написанными на продукт, и общения с ручными тестировщиками. Разработчик не перестанет быть разработчиком, не превратится в ручного тестировщика. Это не его путь. Путь разработчика писать хорошие автотесты.

Задачи у автоматизатора интересные и зачастую сложные. В первую очередь стоит вспомнить про знаменитую пирамиду Фаулера. Модульные, интеграционные, end-to-end тесты подразумевают вдумчивый подход к структуре тестов и выбору инструментов в соответствии с функциональностью продуктов, для которых пишем автотесты. Если говорить о продуктах, разрабатываемых в Veeam, то автоматизатору понадобится работать с REST, WebDriver, Microsoft SQL Server, Amazon Web Services, Microsoft Azure, VMware vCenter, Hyper-V список не исчерпан. У каждого из облаков и гипервизоров свой API и свои скелеты в шкафу. Порой приходится писать код на различных языках программирования, использовать заглушки, семафоры, создавать свои обертки и т.п.

Одну и ту же задачу можно решить по-разному, и автоматизатор ищет наиболее эффективное решение. Вот лишь один из примеров сценарий, реализованный для продукта Veeam ONE. Один из компонентов продукта Business View, который позволяет группировать элементы виртуальной инфраструктуры по различным критериям. Критериев и вариантов их комбинирования очень много, поэтому проверка этой функциональности вручную занимает много времени. Написание автотестов в лоб с имитацией действий ручных тестировщиков было бы неэффективным: тесты для графического интерфейса десктопных приложений, как правило, сложны и трудоемки в разработке, являются хрупкими, их тяжело модифицировать, и выполняются они долго. Мы нашли другое решение: поскольку действия пользователя в UI интерполируются в SQL-запросы к базе данных, мы используем SQL-запросы для создания категорий и групп. Это позволило нам в разумные сроки покрыть автотестами все свойства и операторы, задействованные в Business View.

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

Нужно обратить внимание на качество самих автотестов. Кто сторожит сторожей? Какому автотесту можно доверять? Автотест должен быть эффективным по критерию количество затраченных на него усилий / полученный результат, автономным, стабильным (нехрупким), быстрым, надежным (никаких false positive и false negative). В автотесте должен быть понятный, хороший код с точки зрения возможностей языка программирования, чтобы этот код можно было легко расширять и изменять.

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

Что в Veeam?

В компании Veeam мы будем рады новым боевым товарищам с опытом программирования на C# (например, web-интерфейсы, десктопные приложения, консольные утилиты и т.п.). У нас в Veeam есть много продуктов. Технологии в них могут различаться. В автотестах для нескольких продуктов мы опираемся на REST и WebDriver. Если у вас нет опыта с этими технологиями, но вы уверенно себя чувствуете в написании кода на C# и питаете интерес к автоматизации тестирования, то, возможно, мы также найдем точки соприкосновения.

Мы будем рады вашему резюме и паре абзацев о том, что вас привлекает в автоматизации, о ваших сильных сторонах и профессиональных планах. Пишите нам на ящик qa@veeam.com внимательно прочитаем. Если укажете в теме письма [Хабр] (например, [Хабр] Позиция автоматизатора), будет плюс в карму =)

Да пребудет с Вами Сила.

Подробнее..

Сильные стороны функционального программирования

15.02.2021 16:13:26 | Автор: admin


Привет! Меня зовут Катерина, и я испытываю самые тёплые чувства к функциональному программированию, использую функциональный язык на постоянной основе и даже немного преподаю.

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

Как ФП улучшает программирование


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

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

  1. Код станет более лаконичным и выразительным. Выразительность можно определить как количество идей на единицу кода, и в целом функциональные языки, будучи более высокоуровневыми, оказываются и более выразительными. Например, преобразование каждого элемента в массиве или списке реализуется функциональным однострочником (используя map/foreach/whatever и анонимную функцию), в то время как в императивном стиле пришлось бы организовывать цикл, объявлять переменную для счётчика или итератора и использовать явное присваивание. Для более сложных примеров различие в выразительности только усиливается.
  2. Декомпозиция кода будет происходить более естественно. Принцип Разделяй и властвуй уже прочно закрепился в разработке и является базовым принципом борьбы со сложностью ПО. Речь идёт не о способе построения алгоритмов, а о более общем понятии. Например, даже простую программу, которая сначала читает целиком текст, разбивает его на слова и что-то делает с каждым словом, можно разбить на логические части: само чтение, разбиение прочитанного текста на слова (например, по пробелам) и создание структуры для хранения слов, обход этой структуры с преобразованием слов и печать результата. Каждое из этих действий можно реализовать отдельно и достаточно абстрактно, чтобы затем переиспользовать для решения других подобных задач. Декомпозиция кода на более мелкие и более общие части делает его гораздо более понятным (в том числе и для самого автора кода в будущем), позволяет избежать ошибок копипаста и упрощает дальнейший рефакторинг. Думаю, многим разработчикам приходилось копаться в своей или чужой простыне неструктурированного кода, написанного наспех, чтобы скорее заработало. Человеческому мозгу тяжело удерживать внимание на большом количестве сущностей одновременно и решать одну глобальную задачу сразу (working memory), поэтому для нас вполне естественно разбивать задачи на более мелкие, решать их по отдельности и комбинировать результат. В функциональном программировании эти мелкие задачи выражаются как небольшие вспомогательные функции, каждая из которых делает своё дело и её работу можно описать одним коротким предложением. А построение итогового результата это композиция таких функций. Конечно, разбить код на отдельные переиспользуемые части можно и в ООП, и в чисто императивном низкоуровневом языке типа C, и для этого уже есть известные принципы типа SOLID и GoF-паттерны, но, когда сам язык заставляет программиста думать в терминах функций, декомпозиция кода происходит гораздо более естественно.

  3. Побочные эффекты будут отделены от чистых функций. Чистая функция это функция в математическом смысле, результат работы которой зависит только от входных данных. В ходе вычисления такой функции не происходит ничего лишнего: не меняются значения переменных, ничего не читается и не печатается, не пишется в БД и не выполняются запросы к внешним сервисам. Действительно, вы же не будете ожидать таких действий от, скажем, тригонометрических функций? С помощью чистых функций можно реализовать большую часть логики работы с данными. Не все языки позволяют контролировать отсутствие побочных эффектов и проверять чистоту функций, но сам по себе функциональный подход мотивирует использовать чистые функции, которые работают без неожиданностей.
  4. Код станет проще отлаживать и тестировать. Этот пункт вытекает из двух предыдущих: у нас имеется набор небольших функций, часть из которых чистые, т.е. мы знаем, что их результат зависит только от входных данных. Код становится удобнее отлаживать достаточно проверить, что возвращают используемые функции по отдельности, чтобы понять, как они будут работать вместе. Так же легко пишутся юнит-тесты для чистой логики вашего приложения.

Как ФП улучшает программиста





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

  1. Изучение альтернативной парадигмы само по себе полезно для мозга, поскольку в процессе освоения программирования в функциональном стиле вы научитесь смотреть на привычные вещи по-другому. Кому-то такой способ мышления покажется гораздо более естественным, чем императивный. Можно долго спорить о том, что нужно и не нужно в индустриальном программировании, но там в любом случае нужны хорошие мозги, а их нужно тренировать. Осваивайте то, что не используете в работе: Лиспы, Пролог, Haskell, Brainfuck, Piet. Это поможет расширить кругозор и может стать для вас увлекательной головоломкой. Со временем вы сможете начать применять более элегантные решения в функциональном стиле, даже если пишете на императивном языке.
  2. За функциональными языками стоит серьёзная теория, которая тоже может стать частью ваших увлечений или даже исследований, если вы в той или иной степени хотите связать свою жизнь с computer science. Учиться никогда не поздно, особенно когда перед вами будут наглядные примеры использования довольно занятной теории для решения повседневных задач. Я бы никогда не подумала, что уже после окончания университета буду смотреть лекции по теории категорий, которую мой мозг когда-то отказывался воспринимать, и решать задачки из курса ручкой на бумаге, просто потому что мне это интересно.
  3. Помимо расширения кругозора увлечение ФП поможет вам расширить и круг общения. Возможно, за тусовкой функциональщиков закрепилась репутация академических снобов, которые спрашивают у вас определение монады перед тем, как продолжить общение. Я тоже так раньше думала, пока меня не вытащили на первые функциональные митапы и конференции. Я была совсем неопытным джуном и не знала определение монады, но не встретила по отношению к себе никакого негатива. Напротив, я познакомилась с интересными людьми, увлечёнными своим делом и готовыми делиться опытом, рассказывать и объяснять. Разумеется, в любом комьюнити есть совершенно разные люди, кто-то вам понравится больше, кто-то покажется токсичным и отталкивающим, и это совершенно нормально. Гораздо важнее то, что у вас появится возможность обмениваться идеями с теми, кто смотрит на мир разработки немного иначе и обладает другим опытом.
  4. Самый неожиданный для меня пункт: мне было легче всего найти работу именно на Haskell! На данный момент мой опыт работы чуть больше пяти лет, за это время на двух из трёх местах работы я писала на Haskell, и это был наиболее комфортный и безболезненный опыт трудоустройства. Более того, начинала я тоже с позиции Haskell-разработчика, о чём ни разу не пожалела. На первой работе я получила базовые навыки клиент-серверной разработки и работы с БД. Мы занимались такими же приземлёнными и ненаучными задачами, как и компании, использующие более распространённые языки. На популярных сайтах с вакансиями вы, скорее всего, почти не найдёте ничего по запросу Haskell-разработчик. В лучшем случае найдутся вакансии, где указано, что знание альтернативных парадигм будет преимуществом. Однако, это не значит, что таких вакансий нет. В Твиттере и тематических каналах в Телеграме вакансии появляются регулярно. Да, их мало, нужно знать, где искать, но и хороших специалистов такого узкого профиля тоже немного. Разумеется, вас не возьмут сразу и везде, но свою востребованность вы почувствуете значительно сильнее, чем при поиске работы на более распространённых языках. Возможно, компании могут быть готовы вкладываться в развитие программистов в нужном направлении: не можешь найти хаскелиста вырасти его сам!

Заключение


Появление элементов ФП в популярных языках индустриальной разработки, таких как Python, C++, Kotlin, Swift и т.д., подтверждает, что этот подход действительно полезен и обладает сильными сторонами. Применение функционального стиля позволяет получить более надёжный код, который проще разбивать на части, обобщать и тестировать, независимо от языка программирования. Разумеется, функциональный язык позволяет использовать все перечисленные преимущества по максимуму, предоставляя естественные конструкции с высокой степенью выразительности.

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

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

Почему проекты переписываются и почему это не удается

23.02.2021 04:22:12 | Автор: admin
Извечная тема можно или нельзя переписать большой, работающий продукт с активной пользовательской базой? Ответ, в целом, будет да, можно. Вопрос только как? Наблюдая в прошлом несколько таких попыток (как удачных, так и не очень), данная статья является авторским взглядом на эту проблему.

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


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


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


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


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


Кризис


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


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


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


  • Помните вот ту функциональность, которую просил клиент? Мы отказали из-за нашей текущей базы данных, которая так не умеет.
  • А вот из-за этой, когда-то принятой архитектуры, мы не в состоянии быстро написать реализацию этой задачи.
  • Код старый, там никогда не было тестов, потому их и теперь нет.
  • Фреймворк старый, таких теперь не делают.
  • Язык программирования старый, такие еще делают, но вообще это уже опасно для жизни на таком писать, и новички к нам не идут поэтому, ага.
  • Тут вообще какие-то скрипты для развертывания окружения, которые никто не понимает, а автор давно уволился.
  • Нам просто больно каждый день трогать такой код руками, а вы нам еще никогда не давали времени что-то с ним сделать хорошее, и вот сейчас уже совсем поздно.

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


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


Звук победных фанфар раздается в сознании инженера ровно в момент произнесения фразы сколько времени вам потребуется на переписывание?. Победа! Конечно, 100% времени никто не сможет выделить нужно поддерживать старое, может сделать какие-то небольшие изменения, и все же доделать вот то, что начато. Но это уже не имеет значения, как и общая оценка необходимых ресурсов, как и то, в каких пропорциях будет разделена работа между старым и новым 50/50, 60/40, треть и две трети. В этот момент случается один из важных и опасных фазовых переходов в сознании существующая система начинает считаться временной, соответственно, временными выглядят и неудобства по работе над ней.


Благая весть


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


Если вы это слышите, либо же это вы произносите, то знайте ваш проект, ваша работа в большой опасности.


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


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


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


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


Сложности


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


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


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


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


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


Падение


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


  1. не справились со сложностью ведения точно такого же проекта, и не осознали этого
  2. не обладают всеобъемлющим знанием контекста

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


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


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


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


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


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


Поток


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


Позитивный опыт, накопленный индустрией, говорит нам о том, что код довольно податливый материал. Тут показательна история Twitter, который был плавно, в несколько этапов, перенесен между технологиями, без простоев и вместе со всеми своими пользователями и их данными, причем незаметно для последних. Были заменены подсистемы поиска, рендеринг страниц, хранилище данных и другие компоненты. И вот платформа, начавшаяся как приложение Ruby on Rails, теперь работает в основном на JVM, по пути полностью сменив архитектуру. Пример более чем впечатляющий.


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


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


P.S.


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

Подробнее..

Перевод Почему стоит обратить внимание на подход low-codeno-code

16.02.2021 16:13:42 | Автор: admin

Все мы в последнее время довольно много слышим о платформах low-code/no-code. Платформы без кода обещают сделать разработку программного обеспечения столь же простой, как использование Wordа или PowerPointа, чтобы обычный бизнес-пользователь смог продвигать проекты без дополнительных затрат (денег и времени) на команду инженеров. В отличие от платформ без кода, low-code по-прежнему требует определенных навыков программирования, однако обещает ускорить разработку программного обеспечения, позволяя разработчикам работать с предварительно написанными компонентами кода.

Согласно Gartner, к 2024 году 65% разработанных приложений будут относиться low-code.

Еще в 2017 году я участвовал в раннем сравнительном тестировании производительности традиционной разработки (с использованием Java) и проектом low-code/no-code, основанном на моделях. Результаты были впечатляющими: при использовании метода low-code/no-code производительность увеличивалась в 5-7 раз. Опрос, проведенный компанией No-Code Census в 2020 году, показал прирост производительности в 4,6 раза по сравнению с традиционным программированием.

Low-code/no-code: Фрагментация платформы

Область low-code/no-code довольна сложна и включает в себя многочисленные решения, платформы и субрынки. Например, существуют субрынки, ориентированные на крупные, средние и малые предприятия. Корпоративные платформы low-code/no-code обеспечивают высокую масштабируемость, производительность, безопасность и интеграцию с приложениями предприятия. Они, как правило, дороже остальных. Ниже представлен Магический Квадрант Gartner для корпоративных low-code платформ:

Gartner дает платформе low-code (LCAP) следующее определение: Это платформа, которая поддерживает быструю разработку приложений, одноэтапную раскатку, выполнение и управление с использованием декларативных абстракций программирования высокого уровня, таких как языки программирования на основе моделей и метаданных.

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

Неудивительно, что многие платформы low-code являются платформами управления бизнес-процессами. BPM уже давно поддерживает разработку на основе моделей (Model-driven Development), где нужно нарисовать диаграммы, объясняющие, как должно работать программное обеспечение, прежде чем его создавать. Эта схема похожа на процессный подход BPM, при котором для задания бизнес-процесса необходимо в правильном порядке расположить блоки, представляющие собой подпроцессы. (Самым популярным стандартом отображения процессов, поддерживаемым большинством BPM-платформ, является BPMN). Поэтому процессно-ориентированные решения достаточно популярны. Примерами low-code/no-code платформ для BPM являются Appian, Pega, Outsystems.

Но существуют и другие примеры под эгидой low-code/no-code:

Веб-платформы для использования предприятиями любого размера. Ведущими конкурентами являются WordPress, Wix, Squarespace и WebFlow.

Платформы управления базами данных, начиная от таких, как Mendix, и заканчивая такими, как Airtable. Существуют также low-code/no-code платформы баз данных NoSQL, например, KgBase, предназначенная для построения графов знаний.

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

Разработка мобильных приложений. Большинство платформ low-code/no-code, таких как Bubble, предоставляют возможности адаптивного пользовательского интерфейса, другие предлагают встроенную поддержку ведущих мобильных OC (iOS и Android). Thunkable пожалуй, лучший пример low-code/no-code платформы для разработки мобильных приложений.

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

Другие категории платформ нацелены на определенные области или ниши приложений:

  • E-commerce и онлайн-магазины: лидирующим примером здесь является Shopify.

  • Управление рабочим процессом: отличный пример Monday.com.

  • Приложения ERP (планирование ресурсов предприятия): в качестве интересного примера (также указанного в MQ Gartner) можно привести Zoho. Еще одна важная и впечатляющая платформа для ERP и CRM это Salesforce.

  • Блокчейн и Интернет вещей: Atra.

  • Искусственный интеллект: сейчас мы начинаем наблюдать появление таких инструментов, как C3 AI Ex Machina.

Челленджи low-code/no-code

Платформы low-code/no-code имеют множество преимуществ, но в то же времясоздают определенные трудности и требуют обучения для работы с ними. Многие передовые практики только появляются и относительно незрелы, и следовательно, растет ответственность при их использовании. Что касается традиционного программирования, здесь накоплен огромный опыт, существуют сильные сообщества, а передовые практики задокументированы. Во многих отношениях low code/no-code находится в зачаточном состоянии даже несмотря на то, что разработка на основе моделей существует уже давно (особенно платформы BPM).

Вот некоторые из наиболее серьезных проблем:

1. Необходимость изменения культуры: low-code/no-code требует изменения культуры организации, будь то корпорация или стартап. Изменить культуру для избавления от лишних процессов непросто, это требует схожего видения и одобрения руководства, а также выделения бюджета и полномочий для центра компетенций по цифровой трансформации low-code/no-code.

2. Время и усилия на изучение платформ: low-code/no-code увеличивает скорость и производительность, но инструменты и платформы нетривиальны, и для развития необходимого уровня владения ими требуется время. Это один из наиболее неправильно понимаемых аспектов low-code/no-code. Сложные программные конструкции, такие как вложенные циклы, не так уж и просты на любой платформе.

3. Необходимость использования нескольких платформ: одни платформы имеют более полную функциональность, другие нет. Unqork и Bubble, например, предназначены для любого сценария использования и поэтому предлагают множество вариантов интеграции с корпоративными системами. Кроме того, они могут взять много полезного из других компонентов, специализирующихся в определенных областях; например, Bubble вместе, скажем, с Parabola или плагином Zapier можно использовать для автоматической интеграции. С возможностями управления данными и интеграциями в Parabola или Zapier работать легче, чем с нативными от Bubble. Существуют и другие плагины или технологические компоненты, дополняющие платформы low-code/no-code: посмотрите, например, список технологических партнеров Unqork или полный список плагинов для Bubble.

4. Недостаточность ресурсов и поддержки сообщества: в мире существуют миллионы, или даже десятки миллионов разработчиков обычных языков программирования, множество онлайн-курсов, а также книги и материалы, доступные для таких языков, как Java или C#, есть множество сообществ и ресурсов для аутсорсинга. Совсем иначе дела обстоят для low-code/no-code, особенно для более новых платформ.

5. Сбивающее с толку ценообразование: корпоративные low-code/no-code платформы, как правило, неоправданно дороги. Платформы для среднего и малого рынка менее затратны, но, как правило, менее масштабируемы. А использование нескольких платформ для создания комплексного решения еще больше усложняет вопросы ценообразования.

Это лишь некоторые из основных проблем. Они ясно дают понять, что low-code/no-code не панацея. Тем не менее, такой подход остается серьезной тенденцией для разработки инновационных решений как для действующих предприятий, так и для стартапов.

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

Готовы ли вы к переходу на low-code/no-code?

Примечание переводчика: наша компания предоставляет как low-code/no-code омниканальный облачный контакт-центр Voximplant Kit с широкими возможностями автоматизации обслуживания клиентов, так и serverless-платформу Voximplant для традиционной разработки с набором API для создания голосовых, видео- и текстовых коммуникаций.

Подробнее..

Как мы используем Confluence для разработки требований к продукту

17.02.2021 14:23:34 | Автор: admin


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

Все изменения в требованиях к новой фиче на одной странице


Мы разрабатываем сложные Enterprise-продукты, которые тиражируются для сотен корпоративных заказчиков. В одном из наших продуктов больше ста функциональных модулей и у каждого модуля есть отдельный документ с требованиями. Фичи нового релиза, как правило, затрагивают несколько (от 3 до 20) функциональных модулей.



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

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



Примерно так это выглядит в жизни:



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

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

Подробнее...
В документе с требованиями к функциональному модулю:
Текст изменившейся части требований обрамляется макросом MultiExcerpt. Если изменение небольшое (например, поменялась какая-то одна цифра или небольшое предложение), мы добавляем в макрос немного текста вокруг этого изменения, чтобы читатель понимал контекст.


На странице документа с новой функциональностью:
Добавляем макрос Multiexcerpt include. В нём указываем, какой блок из какой страницы нужно вставлять:


Готовая страница фичи в режиме редактирования выглядит примерно так:


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



Делается это с помощью стандартных макросов Отчёт о свойствах страницы и Свойства страницы.

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



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



Трассировка требований


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

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



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

Для этого мы используем стандартную функциональность меток в Confluence и макрос Результаты поиска.

Подробнее...
На примере функционального модуля Карточка Персоны:
  • Находим все функциональные модули, на которые может повлиять изменения требований к карточке Персоны
  • Добавляем в них соответствующий тег (в нашем случае это #person)
  • Добавляем макрос Результаты поиска на странице требований к карточке Персоны



В режиме редактирования это выглядит так:



А читатель видит так:



Версионирование требований по релизам


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



Так выглядит в жизни переключение между версиями релизов:



Комментирование


Для работы с комментариями мы используем плагин Talk.



Его плюсы:

  • Можно видеть комментарии и отвечать на них в режиме редактирования документа. Это очень удобно, когда надо вносить правки в требования по результатам ревью
  • Нет проблем с параллельным комментированием (особенно если вы планируете переход с MS Word + Sharepoint: не нужно блокировать документ целиком), требования может рецензировать одновременно вся проектная команда
  • Если комментарий оставляют на странице с фичей в блоке с Multi Excerpt, он автоматически появляется в исходном документе требований

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

От стандартного функционала комментирования в Confluence мы отказались, потому что у него были критичные для нас минусы:

  • Нельзя использовать в связке с плагином Multi Excerpt
  • Не видно комментариев в режиме редактирования документа
  • Пропадают комментарии, если изменить текст, к которому они были привязаны

Создание диаграмм и мокапов


Сначала мы использовали MS Visio и экспортировали схемы в растровый формат, а затем загружали в Confluence. Такой подход был неудобен актуальность схем приходится поддерживать в двух местах, для этого нужно слишком много действий.

Как оказалось, в Confluence есть множество плагинов для работы с разного рода графическими объектами (диаграммы, схемы, мокапы и пр). Balsamiq Wireframes for Confluence и Draw.io Diagrams for Confluence позволяют редактировать графические объекты, не выходя из Confluence. На данный момент эти плагины почти полностью покрывают наши потребности.
image

Базовые возможности


Кратко расскажу о базовых возможностях, которые предоставляет Confluence (как и большинство других вики-систем). Чтобы не пересказывать документацию, ограничусь списком того, чем мы в основном пользуемся:

  • Сравнение версий документов. Можно быстро понять, как менялась функциональность от релиза к релизу.
  • Параллельное редактирование одного документа и автоматическое разрешение конфликтов. Ревью документа могут делать одновременно несколько человек и при этом не нужно ждать своей очереди, пока документ заблокирован на редактирование другим сотрудником (как было, когда мы использовали Sharepoint и требования хранились в виде Word-файлов).
  • Шаблоны документов. Мы создали шаблоны по всем основным типам документов (функциональный модуль, фича, протокол совещания)
  • Гибкие возможности разграничения доступа (вплоть до уровня страницы). Это удобно, например, для аутсорсных сотрудников, которым нельзя предоставлять доступ сразу ко всем требованиям
  • Экспорт документов в различные форматы. Очень выручает в тех редких случаях, когда возникает необходимость передачи документов наружу.
  • Интеграция с JIRA. Можно автоматически вставлять статус задач, сроки согласований и прочей информации из тикетов JIRA.

Переход с MS Word


Есть несколько неочевидных вещей, с которыми почти сразу сталкиваешься после перехода с Word на Confluence.

Нумерация заголовков


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



Гиперссылка на раздел


Чтобы внутри документа сослаться на какую-нибудь часть документа или заголовок раздела, нужно сначала добавить макроc Anchor (в русской локализации он называется Анкер), а затем добавить гиперссылку на него из нужной части документа.

Подробнее...
Добавляем макрос Anchor и указываем его имя (Вставить -> Другие макросы -> Anchor):



Так он выглядит в документе в режиме редактирования:



Затем вставляем ссылку на этот якорь в документе (Вставить -> Ссылка -> Дополнительно):

  • Для создания ссылки на другой документ перед названием якоря указываем название документа, на который нужно сослаться, затем символ # и после него название якоря.
  • Для создания ссылки на текущий документ перед названием якоря просто указываем символ #.



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

Цвет фона текста


Сделать нестандартное визуальное оформление текста, в частности выделить фон текста
заливкой, можно с помощью Markdown-разметки (Вставить -> Разметка, Markdown).



Используйте этот код
Для заливки мы используем такой код:
<span style="background-color: rgb(202,225,255);">текст</span>

Подставьте RGB-код нужного вам цвета.

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

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

  • Копирование и вставка из буфера обмена размеченного таким образом текста как правило ведет к потере разметки.
  • Изменить разметку можно только в режиме редактирования исходного кода страницы.

На этом всё. Задавайте вопросы в комментариях!

P.S. Статья основана на базе доклада Лайфхаки Confluence для разработки требований на конференции Analyst Days, видео версию этого доклада можно посмотреть по этой ссылке.

Автор статьи: Ильшат Габдуллин g1r
Подробнее..

ERP-система нет, микросервисный подход да, подойдет для создания маркетплейса. Давайте разбираться, что к чему

19.02.2021 16:11:01 | Автор: admin

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

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

Не используйте для разработки ERP-систему

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

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

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

То есть, грубо говоря, система управления заказами (OMS) сама маршрутизирует потоки (подборы товаров, идентификация позиций товаров по конкретным поставщикам и т.д.). Должны быть автоматизированы все процессы системы: управление каталогом, программы лояльности, витрина и т.д.

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

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

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

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

И в конечном итоге компания жалуется на результат, потому что ожидания не совпадают с реальностью. Ждали резкого взлета в продажах, а получили не более 10% от общего оборота. Все это довольно грустно. Но выход есть.

Сделайте выбор в пользу микросервисного подхода

Как раз его используют крупные торговые площадки.

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

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

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

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

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

Если раньше по ядру мы работали только с продуктовым каталогом (например, просто брали несколько моделей apple 10 и продавали), то сейчас нужно учитывать конкретные единицы товаров apple 10 первого, второго, третьего поставщика, а также склады, номера штрих-кодов, учет по коробкам и их перемещение, то есть большое количество признаков и параметров только одного товара.

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

И самое главное в начале пути - вовремя обойти грабли с неверными ожиданиями и адекватно подойти к процессу создания платформы.

Как начать работу с проектом по запуску маркетплейса

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

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

  • формирование ключевых систем автоматизации маркетплейса в формате To be;

  • построение общей архитектуры компонентов маркетплейса с определением потока данных и нагруженности систем;

  • описание ключевых требований к платформе и функционалу, который нужен для автоматизации маркетплейса;

  • формирование ключевых требований к инфраструктуре.

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

Подробнее..

Консилиум с Eltex разработка ПО

13.02.2021 06:17:09 | Автор: admin

Всем доброго времени суток!

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

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

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

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

Ранее мы уже были в гостях у компании, затрагивали тему технологии беспроводной передачи данных на примере Wi-Fi 6 (IEEE 802.11ax). Нам также удалось не только провести экскурсию по производству, но и застать руководство врасплох вопросами о бэкдорах)

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

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

Кратко о бизнес-процессах

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

Основные этапы разработки и производства

Рассмотрим этапы разработки и производства более подробно. Предприятие активно взаимодействует с заказчиками и анализирует ключевые тренды рынка, что позволяет своевременно выпускать конкурентоспособную продукцию отечественного производства. Идея разработки нового устройства формализуется в виде технических требований при участии архитектора и сотрудников коммерческого отдела и сервисного центра. На этапе проработки требований первостепенная цель - конкретизировать ключевые особенности аппаратной и программных частей, а также согласовать дорожную карту развития продукта. На следующем этапе при участии лаборатории Hardware подбирается электронно-компонентная база (ЭКБ), удовлетворяющая поставленным задачам. В качестве примера можно привести выбор центрального процессора: его характеристики должны соответствовать ожидаемой производительности, целевой себестоимости и предельному энергопотреблению. Ключевыми артефактами данного этапа являются принципиальная и структурная схема устройства. На основе этих схем рисуется топология, после чего заказывается плата. Тут важную роль играет отдел снабжения, который взаимодействует с поставщиками ЭКБ и обеспечивает бесперебойную поставку компонентов для производства устройств.

Этап запуска первых опытных образцов устройства обычно называется Bring-Up и характеризуется взаимодействием отдела разработки и лаборатории HW. Для запуска устройства нужен софт - это зона ответственности отдела разработки. За основу софта берется SDK ключевых ЭКБ устройства и готовится первичный софт, именуемый прошивкой, для возможности проверки основных электронных компонентов, таких как: светодиоды, phy, wi-fi радиомодули.

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

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

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

Софт формируется в релизы - это совокупность работ, которые нужно выполнить к определенному сроку. Для этого используется баг трекер, где фиксируются основные задачи. Разработка релиза делится на несколько этапов: планирование, разработка, стабилизация и выпуск релиза, включающий проверки в эксплуатации. На выходе получается прошивка, которая в дальнейшем используется на производстве для выпуска партий устройств. Рассмотрим, из чего состоит типовая прошивка. Роль основной системы устройства играет одна из версий Linux, модернизированное ядро которой обычно идет в составе SDK производителя основных ЭКБ. Для запуска системы используется загрузчик. На каждое устройство и версию ПО соответствующим отделом разрабатывается и обновляется исчерпывающая многоязычная документация. Вся рабочая документация хранится в системах организации и хранения знаний: Confluence, Wiki.

Следует отметить, что для графического управления устройствами используется Web-интерфейс или софтовый контроллер. За разработку этих систем отвечает отдельная лаборатория.

Используемый стек технологий

Разнообразные языки программирования и технологии позволяют предприятию решать широкий диапазон комплексных задач: от написания модуля ядра, разработки высоконагруженных сервисов, развертывания их в Docker с использованием Kubernetes до создания Android/IOS приложений.

Ресурсы аппаратного обеспечения сетевых устройств зачастую ограничены. Эта особенность определяет стек технологий для создания встроенного программного обеспечения. Соответственно, на предприятии Eltex используется язык Си, как основной язык ядра операционной системы Linux. Широко используется С++, в некоторых лабораториях есть опыт написания модулей на Rust. Для решения узких задач пишутся вставки на ассемблере. В одной из лабораторий для написания высокопроизводительный приложений для телефонии используется язык Erlang. Для отладки кода используются следующие инструменты: отладчики (GDB); средства захвата и анализа сетевого трафика (wireshark); утилиты отладки использования памяти и трассировки системных вызовов (valgrind, strace); статические анализаторы кода (cppcheck, PVS-studio). Для сборки прошивок разворачивается Jenkins, сборки осуществляются в Docker контейнерах.

Обеспечением качества и поддержкой продуктов в эксплуатации занимается отдельный отдел - сервисный центр. Их главная задача - обеспечить выпуск ПО, удовлетворяющего внутренним критериям качества. Они пишут тесты различного назначения (функциональные, интеграционные) на bash и python. Создают инфраструктуру, обеспечивающую поддержку постоянного уровня качества. На каждом из этапов команда взаимодействует с разработчиками, обеспечивая контроль качества выпускаемого ПО: прорабатываются и выполняются тесты как по отдельным задачам, так и по крупным фичам, разрабатываются стенды и схемы интеграционных проверок, модернизируются старые и пишутся новые тесты. Регулярные автоматические тесты позволяют выявить ошибки на раннем этапе. В зависимости от направления и тестируемого продукта используются различные инструменты. Для автоматизации тестов задействуются следующие инструменты: pytest, selenoid, allure, яндекс танк, ansible. Используемые инструменты для логирования: graylog, elasticsearch, influxdb, telegraf, prometheus, grafana. Также стоит отметить, что для организации ci-cd применяется gitlab.

Невозможно представить сетевые устройства без сервисов управления и мониторинга. ПО данного типа может быть как в составе железа (WEB-интерфейс), так и распространяться в виде deb-пакетов или Docker контейнеров (контроллерные решения). Для внешних решений используются языки java, kotlin, go, python. При разработке встроенного WEB-интерфейса используются Angular/JS для фронтенда и lua/C++ для бэкенда.

В компании есть группа, которая пишет Andoid/Ios приложения для мобильных устройств на Java и Swift. Эта группа разрабатывает различные вспомогательные приложения для Media приставок, а также для проекта умного дома/офиса.

Заключение

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

Безусловно, без внимания остались и другие не менее интересные вопросы. Но не все сразу!) Подробнее с темой Вы можете ознакомиться в видеоконсилиуме.

Надеемся, материал был интересен и полезен. Если подобный формат понравится студентам и сообществу Хабра, то постараемся и дальше записывать интересные консилиумы.

Подробнее..

Наш процесс разработки. Побег из черной дыры

25.02.2021 08:12:25 | Автор: admin

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

Мне кажется, что в любой компании, деятельность которой как-то связана с IT, отдел разработки является двигателем бизнеса. Leadership team дает направление движения и прокладывает основные координаты, а development дает тягу и мчит компанию в хорошем случае вперед, по проложенному маршруту. Ну или в некоторых случаях куда-то еще. Мы называем наш development процесс и команду Warp Drive, и в этой статье я расскажу про то то, как он построен и про основные принципы его работы.

Для начала картинка, основных составляющих нашего движка. Упрощенная схема выглядит примерно так:

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

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

В целом процесс, по которому мы идем основан на agile практиках. На вход в двигатель поступают требования от бизнес\команды руководства. Это то, что впоследствии будет преобразовано в составляющие конечного продукта, фичи и апдейты. Раз в 2 недели мы проводим Warp Jump (Sprint Planning) где истории назначаются на конкретных людей в команде и мы идем по стандартному 2-х недельному спринту. В результате прыжка в продукте появляются новые фичи, и они потихоньку накапливаются в Dev Environment. Там они проходят проверку качества, и затем деплоятся на Prod. Для простоты Staging/QA environments в нашей схеме пропущены.

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

Итак - желтые фичи находятся в состоянии квантовой неопределенности. Все новые фичи, которые появились в Dev начинают с этого состояния. Это означает, что на данный момент, мы не имеем точного представления о том, является ли эта фича полезной конечному пользователю, или же она только отвлекает\не работает\работает не как надо\не используется. Ответы на эти вопросы мы можем получить только после того, как фича была задеплоена на Prod Environment и мы увидели обратную связь от пользователей. Если пользователь доволен - фича переходит к подтвержденно-хорошее состояние (зеленая), если что-то не так - подтвержденно-плохое состояние (красная) и должна быть либо отправлена на доработку, либо удалена из системы.

Синие фичи, это Technical Debts, т.е. те улучшения, которые девелопмент команда запланировала сделать для своей собственной эффективности. Это может быть или улучшение инфраструктуры проекта, или архитектурный рефакторинг, либо что-то еще. Т.к. участники Warp Drive сами являются заказчиками Tech Debts и мы знаем, что конкретно мы хотим, то такие фичи не проходят через фазу квантовой неопределенности и поэтому классифицируются отдельно от бизнес фич\требований и обычно просто соответствуют состоянию Confirmed Good. В целом процесс перестроения и патчинга двигателя на полном ходу с помощью Tech Debts завораживает, но я думаю все мы в IT индустрии к этому уже давно привыкли.

Далее пройдемся по деталям и поговорим про анатомию одной конкретной фичи.

Из чего же состоит одна фича на нашей схеме? Во первых в нее входят затраты времени на сбор требований и понимание того, какой мы видим ту или иную функцию. Затем, перевод требований в истории, которые непосредственно пойдут в разработку и их приоритизация. Дальше идут Front-End/Back-End development, иногда подключаем DevOps, если нужно еще и environment докрутить. Затем идут затраты на тестирование/QA. И еще один пункт, это поддержка того, что уже работает в Prod.

Для наглядности, развернем эту картинку на полосу конвейера конвертации топлива warp drive(времени) в одну фичу.

Затраты на реализацию одной фичи у нас делятся на 2 типа: повторяющиеся (на схеме отмечены звездочкой), и неповторяющиеся. Для простоты будем считать, что собирать требования, разбивать на истории, проводить backend/frontend development нам нужно только один раз за жизненный цикл фичи. В то же время есть повторяющиеся операции, которые скорее всего понадобится делать снова и снова, уже после того, как данная функция была выпущена в PROD environment. Такими операциями могут быть тестирование, поддержка, иногда конфигурация среды и прочие сервисные штуки.

Таким образом мы получаем, что каждый раз, когда мы релизим что-то в PROD, за счет повторяющихся составляющих фичи, мы увеличиваем операционную стоимость нашего продукта. Если один релиз скорее всего пройдет незаметно, то релизы множества различного функций со временем накапливаются и начинают работать законы масштабируемости. И, как мы обсуждали ранее, не все фичи одинаково полезны. Одним из побочных эффектов нашего Warp Drive являются фичи в Confirmed Red State(красные). Если мы оставляем в системе красные фичи, которые не несут полезной функциональной нагрузки, они не просто увеличивают кодовую базу приложения, но и прибавляют к стоимости поддержки всего продукта. Если не обращать на этот фактор внимание, со временем продукт обрастает функциями, которые не нужны пользователю, и за него еще и платить нужно все больше и больше. И поэтому это очень важно, для поддержания эффективности продукта с точки зрения usability и операционной стоимости стараться держать положительный баланс зеленых фич приложения, и конечно же избавляться от красных. Именно для этого мы держим постоянный контакт с конечными пользователями и требуем от них обратной связи на те или иные функции. Это является частью нашего feature management process.

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

Здесь мы видим соответствие участников процесса технологиям, которые используются для разработки фич, таким как front-end development, back-end development, support, requirements gathering, и т.д. Нет, процентные показатели на данной диаграмме это не опыт участников в какой-то технологии. Это количество внутренней энергии и заинтересованность человека в чем-то. Например, если мы дадим Василию ковырять Front-End, наверное не стоит ожидать от него супер продуктивности, просто потому что у него с этой частью как-то не сложилось и он оценил свою вовлеченность в эту область в 10%. Василий предпочтет настроить вместо этого базу данных и будет при этом работать с высокой отдачей, потому что это та деятельность, которая ему нравится, и которая наполняет его энергией.

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

Надеюсь, кому-то будет полезен наш опыт и те опорные точки, которые мы учитываем в работе. Если кому-то интересна бизнес часть нашей работы, прошу посетить подкаст моего кофаундера Брендона. Сори, на английском, но есть субтитры. Как и во многом другом, двигатель и командный пост должны дополнять и помогать друг-другу. Многие решения, которыми мы руководствуемся на уровне разработки, продиктованы именно нефункциональными бизнес требованиями.

https://brandoncwhite.com/startup-podcast-build-business-brandon-straight-talk-for-entrepreneurs/

Спасибо за внимание.

Подробнее..

Почему язык Go стал стандартом для DevOps-инженеров

25.02.2021 20:10:38 | Автор: admin

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

В 1960-е годы Кен Томпсон легенда программирования написал компьютерную игру Space Travel для операционной системы Multics. Система была проектом компании Bell Lab, где он работал вместе с Денисом Ритчи. Позже проект закрыли, и чтобы продолжать играть в свою Space Travel, Томпсон решил портировать ее на компьютер PDP-7. Инструменты, которые он создал для порта, затем легли в основу операционной системы Unix.

Томпсон написал в одиночку первые три версии. Для Unix был нужен системный язык так появился B. Позже Денис Ритчи, коллега и друг Томпсона, подхватил разработку и написал язык C. Вот так в основе почти всего, на чем построены современные технологии, лежало желание поиграть в компьютерную игру и пет-проекты для забавы.

Кен Томпсон построил блестящую карьеру исследователя в области computer science. В середине 2000-х он устроился в Google, где вместе с Робом Пайком и Робертом Грейсмером создал Golang один из самых популярных языков последнего времени.


Go придумывали как простой язык для всего

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

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

Кен Томпсон

Создатели хотели решить проблемы медленной сборки программ, неконтролируемых зависимостей, сложной разработки инструментов и проблем межъязыкового взаимодействия. За основу языка они взяли C, Pascal и Oberton и попытались собрать из них все лучшее. В итоге они стали делать язык с очень простым синтаксисом, строгой статической типизацией, автоматической сборкой мусора и простыми средствами для управления многопоточностью.

Golang анонсировали в 2009 году, в 2012 состоялся релиз. Язык быстро стал набирать популярность, но и сталкивался с критикой. Ключевую фишку языка простоту многие разработчики посчитали и главным минусом.

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

Но такая критика была и не совсем критикой для создателей языка. Сам Роб Пайк описывал язык почти также, но в отличие от критиков, не говорил о невыразительности как о чем-то плохом:

Ключевой момент здесь, что в гугле работают не исследователи. Они, как правило, молоды, идут работать после учебы, где, возможно, изучали Java, или C/C++, или Python. Они не смогут сразу разобраться в навороченном языке, но в то же время мы хотим, чтобы они создавали хорошее ПО. Именно поэтому язык должен быть прост для понимания и изучения.

Тем не менее, уже в 2012 году многие разработчики увидели перспективы Go в тех областях, для которых его изначально не задумывали. В своем твиттере Дерек Коллисон писал:

* Прогноз: в течение следующих двух лет Go станет доминирующим языком для IaaS, PaaS и оркестрации.

Так и произошло почти в то же время, когда создавали язык, в IT начала стремительно развиваться культура DevOps, в которой Go почти сразу стал стандартом.

19% в DevOps планируют использовать Go в будущем, около 10% уже используют Go19% в DevOps планируют использовать Go в будущем, около 10% уже используют Go

DevOps придумывали как agile для инфраструктурщиков

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

Рано или поздно ошибку устраняли (или нет), и все начиналось заново.

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

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

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

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

В то время еще не было термина Devops была только идея. Я написал в твиттере, что было бы здорово провести конференцию в Европе и обсудить саму идею. Agile System Administrators так себе название для мероприятия, поэтому мне предложили назвать его DevOpsDays с этого и началось движение Devops.

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

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


Почему Go и DevOps идеально подошли друг другу

Когда в Google начали разрабатывать Kubernetes у команды уже накопилось огромное наследие инструментов для контейнеризации. Но Кубер начали писать с нуля, поэтому встал вопрос выбора языка. Джо Беда, основной разработчик сервиса, рассказывал, что в Гугле используются многие языки не только свои разработки и они выбирали между С/С++, Java и Python.

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

Java не подошла, потому что разработчики стремились сделать установку простой на как можно более широком количестве платформ. Python откинули из-за динамической типизации.

А вот Go по словам Беды был и не слишком высокоуровневым, и не слишком низкоуровневым. Список причин, почему команда Kubernetes выбрала его, довольно широк:

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

  • Быстрые инструменты. С ними мы подсели на скорость разработки, пишет Беда.

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

  • Анонимные функции.

  • Сборка мусора, о которой не надо задумываться.

  • Строгая типизация.

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

Три основные причины

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

  • У него самая простая для использования многопоточность. Горутины и Каналы фичи, которые хвалят даже те, кто невзлюбил Go.

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

По сравнению с Python, Ruby или Node.js, установка единственного исполняемого файла мечта инженеров по эксплуатации. Конечно, это вовсе не такая большая проблема с учетом все более широкого использования Docker, но отдельные исполняемые файлы еще и уменьшают размер контейнеров, пишет Сильвиан Валлез.

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

Что вы сами думаете про Go? Как и почему используете? Заходите к нам в сообщество там мы постоянно разбираем различные проблемы и задачи из сферы Devops, обсуждаем вещи, которые пригодятся и на собеседованиях, и в работе.

Подробнее..

Категории

Последние комментарии

© 2006-2021, personeltest.ru