TECH · 30 марта 2017, 14:40 · yankoits - Journalist в dev.by
«В Ruby-сообществе люди больше думают про бизнес, а не про код»

Лидер минской .NET user group Роман Бугаев в новом проекте сменил C# на Ruby — и не остался разочарованным. В преддверии RubyConf 2017 Роман поделился с dev.by своим видением Ruby и рассказал, почему многим разработчикам стоит попробовать этот язык.

Фото: Андрей Давыдчик

Чем хорош Ruby: гибкость, инфраструктура, сообщество

— Я работаю с компанией Payfort, где мы занимаемся проектом по процессингу карточных транзакций — приёмом платежей от Visa и MasterCard. Это аналог Stripe, но для стран Среднего Востока: Саудовской Аравии, ОАЭ, Египта, Катара. Проект работает в режиме стартапа: он небольшой и в плане команды (нас четверо), и в плане нагрузок. Сейчас мы пытаемся найти нишу, много экспериментируем. Поэтому и выбрали Ruby — платформу, которая позволяет быстро и легко делать эксперименты, проверять их и делать на их основе выводы.

Главный плюс языка Ruby — его гибкость. Мы даже проводили эксперимент: стояла задача подобрать параметры для одного из банков, и над решением параллельно работали две команды, наша и ещё одна в Иордании. Коллеги использовали Java и PHP, и для подбора параметров им понадобилось порядка недели. Мы сделали то же на Ruby за день-два: просто заходили на продакшн, включали IRB-консоль и изменяли параметры в ней — без перекомпиляции, сборки, повторного деплоя. Банк делал вызов, мы проверяли, как работают параметры, и меняли их, если требовалось.

Роман Бугаев

Ещё один плюс — хорошая инфраструктура. Про Sinatra и Ruby on Rails и рассказывать не нужно — даже те, кто никогда не интересовался Ruby, знают, что эти фреймворки сделаны хорошо. Есть достаточно мощные ORM-системы — например, хорошо работает Active Record, хотя многие его недолюбливают. Ruby вполне подходит для построения «модных» систем на основе микросервисов, в которых смешивается код на разных языках: в нём есть поддержка gRPC (Google Remote Procedure Calls) и все необходимые сериализаторы, включая JSON и Protobuf. Подключать любые базы данных — и SQL, и NoSQL — тоже очень легко.

В Ruby on Rails очень хорошо реализован MVC: Мартин Фаулер, автор известных книг о паттернах и архитектуре ПО, когда-то говорил, что именно реализация в Ruby самая правильная и каноничная. Но опытных разработчиков это не удивит: её уже успели скопировать в разные языки, в том числе в C#.

Мы используем в проекте подход Infrastructure as Code: все серверы и балансировка сети прописаны в коде. В Ruby есть много хороших инструментов для такого подхода, конкретно мы используем Chef. Поскольку работаем с карточками, ещё один важный момент — безопасность. Тут у Ruby тоже всё хорошо: существует большое сообщество, которое выкладывает много кода в open source. Есть готовые инструменты, которые позволяют определить потенциальные уязвимости и найти для них патчи.

Одни и те же библиотеки можно использовать и близко к фронтенду, и в глубоком бэкенде — это очень удобно. Скачиваешь, например, во время развёртывания Terraform state с Amazon Web Services — и ничего нового подключать не нужно, для доступа к библиотекам используется RubyGems.

Ещё в Ruby отличные инструменты тестирования — и для юнит-тестов, и для интеграционных. Думаю, именно Ruby завёл моду на test-driven development, behavior-driven development и прочие -DD. Ещё один плюс — удобные DSL (domain specific languages). Их много, некоторые из них максимально приближены к естественным языкам — их вполне могут использовать непрограммисты, чтобы писать спецификации или даже изменять поведение продукта.

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

Прикладной инструмент с быстрым входом

Разговоры о том, что на Ruby не написано ни одного большого проекта — неправда. Тот же Stripe, стартап-миллиардер, с которым мы конкурируем, использует Ruby в качестве базового языка. Понятное дело, обрабатывать большие данные или держать огромные нагрузки на Ruby смысла нет, да и машинное обучение на нём не построишь — для всего этого лучше подойдут Go, Python или та же Java.

Ещё с предыдущей компанией мы всегда старались подбирать для каждой задачи правильный инструмент: если лучше подходит Java — берём Java, если .NET — .NET, то же самое с Go, Scala. Ruby при таком подходе очень хорош, поскольку у него несложная кривая обучения: через два-три месяца после знакомства с языком ты можешь довольно комфортно писать на нём любой код. Для входа в тот же C# понадобится намного больше времени.

Думаю, именно поэтому Ruby иногда называют «языком для хипстеров». Он очень хорош для быстрого старта: выглядит, как английский язык, работает при соблюдении минимальных правил. На Coursera есть куча курсов «Как начать стартап», и в качестве основы там часто берут Ruby. Если знаешь английский, то сможешь писать простые вещи почти без подготовки. Именно поэтому язык часто выбирают в качестве первого языка для входа в профессию.

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

Зато Ruby позволяет абстрагироваться от этих сложностей и сконцентрироваться на прикладных задачах. Сейчас мы в компании рассматриваем варианты написания отдельных сервисов на Go, но я думаю, что Ruby останется нашим базовым инструментом, поскольку с ним действительно очень просто. Там, где в большинстве языков потребуется 10-12 строк, в Ruby хватит трёх — и можно идти в продакшн. А весь хороший инструментарий, который я упоминал, позволяет легко организовать непрерывную доставку и непрерывную интеграцию.

Ruby — очень прикладной инструмент, кому-то он даже может показаться скучным. Но как шутят о PHPшниках, представителях одной из древнейших профессий веб-программирования: «Им настолько скучно думать про разработку, что они начинают думать про бизнес — и в итоге получаются фейсбуки и вконтакты». Думаю, с Ruby та же история.

Почему Ruby стоит попробовать (и как это сделать)

Разработка со временем становится всё более мультипарадигменной. Большинство популярных языков полнофункциональны, на них можно делать практически всё, и выбор конкретного языка становится делом вкуса. Разные базы данных, платформы, операционные системы — всё уживается в одном проекте. Моя предыдущая команда из 10 человек использовала в одном проекте 12 различных баз данных! А за счёт такой мультипарадигменности идеи одной платформы регулярно переходят в другие — и это интересно и полезно.

Я остаюсь лидером .NET user group, по-прежнему слежу за новинками в .NET. C# — очень мощный язык программирования, который значительно влияет на другие языки. В интернете даже шутят, что со временем все языки превратятся в C#. Но один из негативных моментов .NET — платформа очень сильно разрослась и требует от разработчика много знаний о себе. В Ruby-сообществе, как мне кажется, люди больше думают про бизнес, про то, как лучше сделать конкретную «фичу» — и не заморачиваются о том, как язык работает изнутри и как правильно писать код.

В целом, в Ruby я для себя не нашёл ничего нового. Здесь нет ни одного «вау», ничего по-настоящему необычного — в этом плане язык напоминает мне Go. Наверное, по нему даже ни одного PhD не написали, в отличие от какого-нибудь Scala с огромным количеством особенностей, которые удивляют, заставляют задуматься или даже переосмыслить подход к программированию. Но эта «обычность» — тоже преимущество: не надо тратить много времени, чтобы понять какие-то новые концепции, и ты не отвлекаешься от основных задач.

Моё первое знакомство с Ruby произошло через IronRuby: окружение, которое компилирует код на Ruby в .NET и позволяет запускать его на Windows. Едва ли кто-то хвалит этот интерпретатор, да и сами рубисты его не любят, но если кто-то из дотнетчиков хочет попробовать Ruby, начинать с него можно. А для джавистов, в свою очередь, есть JRuby. Можно написать маленькую библиотечку, подключить её к своему проекту и посмотреть, что получится. Плохо точно не будет: расширение кругозора — всегда хорошо.

Кстати, Microsoft поддерживает Ruby в Visual Studio и Visual Studio Code. Я пишу на Ruby именно в VS Code. Всё, что для этого потребовалось — установить плагины для поддержки синтаксиса. Попробовать Ruby просто – при случае обязательно сделайте это.

О трендах Ruby — в Минске

2 апреля на минской площадке Space состоится RubyConf 2017, где перед гостями выступят мировые звёзды разработки на Ruby и RoR. Подробнее — в нашем календаре.

Источник: dev.by
Новые комментарии
Angular другой. Совсем другой. React и Vue похожи. Перешел с vue на react. Но только лишь потому-что использую react-native, а weex ещё только рождается в муках. Ну и мне нравится писать всё в js файле, хотя uve это тоже поддерживает. Vue вообще обалденный и легкий в освоении. Всем советую. И вообще. Этот фрейворк уже давно используется, а не только появляется. Bit не слышал, а жаль. Но у меня нет пока частных репозиториев. Styled Components - Надо будет ещё разок посмотреть. Не разобрал практической ценности для себя, если честно. Пытался втиснуть в новый проект, но отвергли. Так пока и не получилось что-либо создать на этом фреймворке. Ну и я с реакт-нативе в основном работаю, а не с реактом. Apollo GraphQL - Крутая вещь. Всем советую. Забыть как страшный сон REST API и перейти на gql. И пофиг на какие-то там лицензионные сомнения. ИМХО - это будущее. И не только с реактом работает. Авторизация по JWT, GraphQL endpoint, db loader и упирод воевать с кодом! Всё очень просто. Написал резольвер и больше не паришься над одним и тем же запросом в базу данных для разных endpoint. Ну да, есть момент насчёт того, что БД будет дергать и вместо кучи запросов от клиента будет куча запросов к БД. Но и это оптимизируется, сокращается, так что всем советую. выбирал клиент для graphql между Relay и Apollo. Apollo однозначно победил. А тут еще 2 версия на подходе и модульные сборки. В итоге у меня и клиент и сервак от аполло. Сервак - набор тулкитов, конечно. Имплементация от graphql-js
ilya.labacheuski
24.09.2017 в 14:43
4 open source проекта, которые будут популярны в 2018 году

Обсуждение

Missing-male
+2

это была реклама Ruby

63637f4ec5ea136f9d17ce151501368e?1401052531
+10

больше думают про бизнес чем про код? - звучит как антиреклама для меня

Missing-male
+4

Это ж национальная идея - фигак-фигак и в продакшон =)

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

Missing-male
+3

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

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

Missing-male

Бизнес же - это не софт писать. Это продавать то, что может быть ещё даже в концепте не реализовано. С надеждой что "авось нахватаем правильных программистов и авось прокатит". Главное потом вовремя спрыгнуть на то место работы, с которого бизнесмену либо до шарабана, что там со старым проектом, либо "ответственный ПОДЧИНЁННЫЙ наказан и уволен".

А почему вообще ПРОГРАММИСТЫ должны думать про бизнес? ПМы не справляются? Я думал, наоборот, ПМы и прочие сеньёры должны думать, как балансировать между стоимостью проекта и оптимальным для неё качеством. А потом всякие финтехи удивляются ещё "о, а чё это у нас такие менеджеры крутые, а код хуже чем у остальных".

37640c51785789e27788caddebdb511b?1365496968
alex.poklonsky
– Solution Architect в EPAM

>>Вот потому что у нас программисты не думают про бизнес, у нас и царство аутсорса.

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

1) ну раз вы пишете про то что "у нас" так вот каким образом программисты у нас, которые "думают про бизнес", адресуют задачу продажи и продвижения продукта за рубежом?

2) каким образом программисты, "думающие про бизнес" у нас адресуют заключение зарубежных контрактов на разработку софта какой-то определенной тематики?

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

Missing
+1

Соглашусь лишь с одним тезисом, стартовать проект лучше на языке с высокой степенью выразительности и гибкости Java, Golang, Rust и т.д. не самый лучший выбор. Сам Ruby в статье переоценён, возможно это вау эффект после .net платформы, которая до сих пор крайне скудна на open source, не кроссплатформенная и т.д. Определенно те кто активно пишет на .net со мной не согласятся ;)

Missing-male

Говорят, что Golang не сильно хуже питона (ИМХО самый простой из распространённых). Но например для замены .NET там ещё пилить и пилить (много TODO вместо реализации в коде конкретно под win). Rust что-то не вызвал восторгов вообще. Мозилловцы вообще не понятно о чём нынче думают, даже браузер угробили.

Missing

Если сравнивать Go c Python то первый крайне не выразителен второй крайне медленный, Не понял вашего тезиса о "не сильно хуже", он явно не раскрыт, по какому параметру эта оценка?

В принципе я зря поставил Java, Go, Rust в один ряд, все же они имеют разное назначение, по сути Java - прикладное/middleware ПО, Go для решений middleware, Rust для системного.

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

Missing-male

В плане выразительности/читабельности.

B993ebcd20d5803b01e1810b59038c5b?1505858797

у вас старые сведения про .net, давно полностью открыт и не менее кроссплатформенен, чем другие (а напомните, можно ли на java, golang, rust делать приложения под ios?)

Missing-male

Ссылку пожалуйста на исходники WinForms или WPF. Или хотя бы реализацию WebClient для .NET 4.6.2

B993ebcd20d5803b01e1810b59038c5b?1505858797
+1

WebClient - https://referencesource.microsoft.com/#System/net/System/Net/webclient.cs,c35cd3c5ea3f4938 (дамп рефсорцов под .net 4.6) + corefx репа на гитхабе для .net core: https://github.com/dotnet/corefx/blob/master/src/System.Net.WebClient/src/System/Net/WebClient.cs#L19

WinForms/WPF - устарелые технологии. Или мне в ответ найти проприетарные джавовые либы и попросить линк на сорцы к ним? Таже джава насктолько открыта, что гугл чуть не поимел иск на 9млрд из-за нее.

Missing-male

Допустим про WebClient мой косяк, т.к. когда я пробовал это дело запустить под .NET Core, его ещё не было.

Но без WinForms/WPF тоже никуда. Тысячи программ для десктопа сами себя не перепишут. Путь "весь софт в веб" - для наивных хомячков, у которых кроме планшета/телевизора с браузером тупо и нет ничего.

Про Java я как бы и не спорил что она огорожена, оды ей не пою. Как и .NET'у впрочем. "чуть-чуть открыт" это совсем не "полностью открыт".

Missing

Приходилось как то попробовать руби и скажу вам что он мне не понравился исключительно ввиду его ужасного синтаксиса. Как вообще можно программировать на языках у которых не си-подобный синтаксис (T-SQL не в счет ;) )? - это первое, субьективное.

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

Третье, производительность - незнаю, как сейчас, но еще года 3-4 назад у руби были большие проблемы с производительностью и многопоточностью.

Код руби не компилируется а сразу же исполняется интерпретатором поэтому можно менять код прямо на сервере. (Кстати если делать MVP эксперименты на дотнете и код C# заливать прямо на сервер и там же компилировать - то что мешает тогда менять код прямо на сервере без дополнительного деплоймента?)

з.ы

Еще что-то я не совсем понял про какие-то параметры которые на Жаве и Пыхапе 2 недели надо программировать?!?! а на руби 2 дня!?!?

Для любителей дотнета и си-подобности я бы рекомендовал посмотреть nodejs. Если например писать код под nodejs его тоже можно прямо на сервере менять(потаму что джаваскрипт), если для кого то это является проблемой :)

Missing

"начинают с C, потому что он ещё сложнее."

Улыбнуло

Missing
+3

ruby пора в список умирающих яп


Авторизуйтесь, чтобы оставлять комментарии

Использование материалов, размещенных на сайте, разрешается при условии прямой гиперссылки на dev.by. Ссылка должна быть размещена в подзаголовке или в первом абзаце публикации.
datahata — хостинг в Беларуси