Ruby *

Статья из моих архивов

Недавно видел на хабре спор по поводу того, что нам не нужны никакие скриптовые языки, кроме javascript. Утверждение, конечно, спорное, но меня заинтересовала возможность применения javascript на сервере.Поиски привели меня сюда. Из всех представленных там решений, я почему-то (просто оно с первого раза встало и заработало) выбрал библиотеку Node для google v8.

Установка достаточно проста: сначала устанавливаем v8. Его либо можно скачать отсюда, либо, если у вас ubuntu (у меня 9.04, не знаю, что там с другими версиями и дистрибутивами), то можно установить libv8 из репозиториев. Сам Node берем здесь.

Что происходит, когда GitHub берётся за собственную безопасность? Они пишут код для защиты кода — и активно используют для этого CodeQL. В этой статье команда Product Security Engineering рассказывает, как настроить масштабный автоматический анализ уязвимостей, зачем создавать свои пакеты запросов и как с помощью CodeQL находить ошибки, которые невозможно поймать обычным поиском по коду.

Есть множество сервисов и программ по сборке программных пакетов: OpenSuse Build Service (OBS), koji. Fedora copr, rpmbuild, mock.

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

Зачем же еще понадобилось дополнительное средство по организации сборки rpm пакетов и репозиториев?

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

Один из самых вредоносных принципов в разработке, когда-либо получивших широкую известность — YAGNI. Его озвучил Рон Джеффрис в 1998, а спустя более двадцати лет — еще и Кармак подлил керосин в огонь со своим: «Неопытным разработчикам трудно оценить, как редко разработка архитектуры с учетом будущих требований приводит к успеху».

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

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

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

25 апреля, DUMP EKB, Екатеринбург

Крупнейшая конференция разработчиков на Урале, куда приезжают более 2000 человек! Конференция, которая традиционно собирает топовых IT-экспертов со всей страны. В 12 секциях прозвучат десятки докладов ТОЛЬКО на актуальные темы. Впервые в этом году — новая секция: TechLead. А также — Backend (2), Frontend, Testing&QA, Team, Product, ML&DS, BA&SA, DevOps, Design, Science, круглые столы, воркшопы, нетворкинг и афтепати.

С версии 3.0 в руби появились неблокирующие файберы, с помощью которых писать код с асинхронным вводом-выводом стало заметно удобнее. В данной статье мы напишем свой простой планировщик для файберов, чтобы лучше разобраться, как работают более сложные планировщики, типа socketry/async.

Программирование — это не только алгоритмы и логика, но и удивительное разнообразие синтаксиса языков. Работая над новым средством подсветки синтаксиса для llamafile, разработчик Justine Tunney* исследовала 42 языка программирования — от классического C и экзотического Tcl до мощного Ruby. 

Justine делится своими открытиями о том, насколько причудливым и непредсказуемым может быть лексический синтаксис. Например, триграфы в C — устаревший инструмент для поддержки клавиатур с ограниченными символами, фиксированные длины строк в FORTRAN, вложенные комментарии в Haskell или строки с двойными квадратными скобками в Lua. Ruby вообще оказался чуть ли не самым сложным языком для подсветки из-за его контекстно-зависимого синтаксиса.

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

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис

Язык Crystal каждый раз удивляет меня. Я думал что язык с синтаксисом Руби не может быть быстрым как Си. Я думал что учитывая что его авторы сидят на Маке или Линуксе его никогда не портируют на винду. Я думал что не справятся с многопоточностью учитывая насколько это усложняет шедулер. И уж совершенно точно я был уверен что портировать его на микроконтроллеры нереальная задача - большой рантайм, ориентированная на GC стдлиба.

Сейчас я покажу как можно писать для микроконтроллеров на Crystal.

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

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

Автор репозитория @BenjDicken создал забавную визуализацию производительности каждого из языков. В одной из визуализаций из визуализаций Ruby по бенчмаркам Ruby оказывается третьим с конца.

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

Для тех, кто не в курсе в мире веб разработки существует фреймворк Ruby on Rails. Фреймворк горячо любим автором и сообществом и используется для создания полнофункционального сайта или по-другому веб приложения. Но все ли знают и понимают, как оно там вообще работает?

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

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

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

Делюсь лайфхаком по уменьшению размеров Docker-образов. Как-то нам попалась на поддержку и развитие CRM-система, написанная на Ruby...

Обновили Ruby-пакеты и под них код, написали Dockerfile. Первая сборка была удручающей: образ в 2Гб. Это нормальный размер, если ты собираешь образ с Torch и другой ML-штуковиной, но CRM - нет. В результате дальнейших действий, удалось сократить размер образа до 200Мб.

Привет! Меня зовут Дима, я архитектор в Купере. Сегодня расскажу о шаблоне проектирования Strangler, который мы использовали для поэтапного выноса бизнес-логики из монолитной системы в отдельный сервис. 

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

На примере простых алгоритмов (вычисление расстояния между точками, сумма членов геометрической прогрессии, формирование массива простых чисел по алгоритму Эратосфена, числа Фибоначчи) сравниваются три языка программирования - Lisp, Python и Ruby. Сравнение проходит по следующим параметрам: компактность и читаемость кода, скорость работы.

Привет! Меня зовут Юрий, я старший разработчик в Купере в команде Ruby Platform, занимающейся разработкой внутренних библиотек, инструментов мониторинга и поддержки микросервисов.

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

Из данной статьи вы узнаете:

- общий принцип работы контрактных тестов;

- о проблемах, с которыми мы столкнулись при внедрении контрактного тестирования и как их решали;

- как мы разработали свое решение для контрактного тестирования Ruby-приложений;

- о настройке CI/CD для автоматизации контрактных тестов.

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

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

Библиотека Rumale создана для того, чтобы сделать машинное обучение доступным и удобным для разрабов на Ruby. Она имеет большой выбор алгоритмов и инструментов, аналогичных тем, что можно найти в Scikit-learn для Python.

Краткий формат статьи выбран из-за сходств с Sckit learn.

Привет! На связи Миша Меркушин. Я тимлид команды Ruby Platform, ответственной за разработку внутренних библиотек и улучшение архитектуры микросервисов на Ruby в СберМаркете. Эта статья про архитектурный паттерн Outbox и инструмент, который мы создали и итерационно развивали внутри команды и лишь недавно «выпустили» его в мир. Он решает проблему обеспечения надежной и согласованной отправки сообщений из приложения, гарантируя, что сообщение будет отправлено после успешного завершения транзакции базы данных.