Ruby *

Всем привет! Мы вовсю готовимся к RailsClub, который состоится 23 сентября (ааааа, это уже на следующей неделе!!). Программа на сайте, 500 крутых рубистов уже зарегистрировались, ждем только тебя! Еще можно успеть заскочить в последний вагон и поучаствовать в главном Ruby событии года в России.

У Павла Аргентова получилось очень интересное интервью с потрясающим человеком. Luca Guidi — семьянин, независимый OSS разработчик, автор Ruby фреймворка Hanami.

Привет!

Мы вовсю готовимся к предстоящей конференции RailsClub 2017 (все случится 23 сентября) и беседуем с нашими спикерами о жизни и программировании. Сегодня Михаил Моргунов разговаривал с Richard Schneeman из Heroku, Ruby Hero 2016, Топ 50 Rails contributors.



Почему в докладе ты хочешь поговорить о потоках в Ruby?

Вы видели результаты бенчмарков MJIT? Они удивительные, правда? MJIT буквально выносит все остальные реализации без вариантов. Где он был все эти годы? Всё, теперь с гонкой закончено?

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

MJIT? TruffleRuby? Что это всё такое?

MJIT — это ответвление Ruby на Github от Владимира Макарова, разработчика GCC, где реализована динамическая JIT-компиляция (Just In Time Compilation) на самом популярном интерпретаторе Ruby — CRuby. Это отнюдь не окончательная версия, наоборот, проект на ранней стадии разработки. Многообещающие результаты бенчмарков были опубликованы 15 июня 2017 года, и это основной предмет обсуждения в данной статье.

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

В этом руководстве мы создадим свой первый проект в Hanami, сделаем простое веб приложение. Мы коснемся всех основных компонентов фреймворка и покроем все написанное тестами.

Привет! Сегодня публикуем интервью с Ником Сатерером. Ник создатель Trailblazer, автор нескольких гемов и новых слоев абстракции в Rails, Rails contributor. Накануне RailsClub 2017, где Ник будет делать доклад, Дмитрий Матвеев пообщался с ним о его работе и взглядах на развитие Rails.

Привет! Мы готовимся к RailsClub 2017 и традиционно беседуем с нашими любимыми спикерами. Сегодняшний герой — человек, получивший Ruby Hero Russia в прошлом году — Антон Давыдов. Антон OpenSource-энтузиаст и один из кор-разработчиков Ruby-фреймворка Hanami. Вольдэмар Дулецкий расспросил его о работе и взглядах на Ruby-разработку.

Перечисления (enumeration) по определению это — «действие упоминания некоторого количества чего-либо один за одним». В программировании, вместо упоминания, мы выбираем любое действие, которое хотим произвести, будь то простой вывод на монитор или выполнение некоторого рода выборки и/или преобразования над элементом.

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

Всем привет! Соскучились по нам? ) Мы уже готовимся к новой встрече. Сегодня расскажем о том, что будет на RailsClub 2017 и о том, как еще можно попасть в программу!

23 сентября, конгресс-центр Технополис Москва. Регистрация на сайте.

Итак, что будет:

Здравствуй, Хабр! На днях мы выпустили RubyMine 2017.2, новую версию нашей IDE для Ruby и Rails, и спешим рассказать о новинке.

• Docker Compose
• Отладка приложений в Docker Compose
• Автокоррекции RuboCop
• “Хлебные крошки” для Ruby
• Улучшения поддержки JavaScript
• Новое в VCS
• Пользовательский интерфейс
• Другие улучшения

От переводчика: «Elixir и Phoenix — прекрасный пример того, куда движется современная веб-разработка. Уже сейчас эти инструменты предоставляют качественный доступ к технологиям реального времени для веб-приложений. Сайты с повышенной интерактивностью, многопользовательские браузерные игры, микросервисы — те направления, в которых данные технологии сослужат хорошую службу. Далее представлен перевод серии из 11 статей, подробно описывающих аспекты разработки на фреймворке Феникс казалось бы такой тривиальной вещи, как блоговый движок. Но не спешите кукситься, будет действительно интересно, особенно если статьи побудят вас обратить внимание на Эликсир либо стать его последователями.

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

Традиционная встреча рубистов с докладами, общением и пиццей состоится 20 июля в офисе компании Rambler&Co!

Цените интегрированные системы

Ruby on Rails можно использовать для разных целей, но его конек — это монолитные интегрированные системы. Такие системы нацелены на решение всей задачи совокупно. Через Rails проходит все, начиная от генерации JavaScript для мгновенного обновления страниц, и заканчивая миграцией базы данных от одной версии к другой, когда проект уже в эксплуатации.

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

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

Это вторая часть моего руководства о том, как самостоятельно администрировать Redmine в долгосрочной перспективе. Первая часть была посвящена управлению собственной версией Redmine с помощью Git (ссылка на перевод).

Имея собственный репозиторий Redmine, пришло время ...

Приглашаем разработчиков, тимлидов и всех, кто так или иначе связан с разработкой на Elixir, принять участие в RamblerElixir Meetup, который состоится 14 июня 19:00, в среду, на уютной мансарде Rambler&Co.

Ни одна парадигма

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

В Rails — это не так. Это не один, идеальный крой ткани. Это одеяло. Совокупность многих разных идей и даже парадигм. Многие из них, как правило, противоречат друг другу, если их сравнивать друг с другом и один за другим. Но это не то что мы пытаемся сделать. Это не одно большое соревнование, в котором должен быть объявлен один победитель.

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

Тема может и банальная, но когда программа начинает работать как то не так, и вообще вести себя очень странно, часто приходится читать логи. И много логов, особенно если нет возможности отлаживать программу и не получается воспроизвести ошибку. Наверно каждый выработал для себя какие то правила, что, как и когда логировать. Ниже я хочу рассмотреть несколько правил записи сообщений в лог, а также будет небольшое сравнение библиотек логирования для языков php, ruby и go. Сборщики логов и системы доставки не будут рассматриваться сознательно (их обсуждали уже много раз).

Соглашение над конфигурацией

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

Кого волнует, в каком формате описываются ваши первичные ключи в базе данных? Действительно ли это важно, если речь идет о «id», «postId», «posts_id» или «pid»? Достойно ли это решение постоянного обсуждения? Нет.

Это вторая часть из серии постов о Shrine. Цель этой серии статей – показать преимущества Shrine над существующими загрузчиками файлов.

---

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

Это первая часть из серии постов о Shrine. Цель этой серии статей – показать преимущества Shrine над существующими загрузчиками файлов.

---

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

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

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

Введение

В доисторические времена высокопроизводительные Web-приложения можно было писать, в основном, на C или C++. Поддерживать такие приложения было не просто дорого, а очень дорого.

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

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

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

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

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

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

Так почему же Crystal?