До RailsClub 2017 совсем немного (кстати, даже если вы не идете, не забывайте голосовать за Героев Руби). Сегодня хотим познакомить поближе еще с одним нашим гостем — Piotr Solnica, автором rom-rb и dry-rb и, как Петр пишет про себя, «all-around OSS contributor».
Как ты считаешь, какая самая большая задача сейчас стоит перед Ruby и RoR сообществом?
Самая важная задача для нас заключается в том, чтобы доказать, что стоит выбирать Ruby для новых проектов, что это жизнеспособная технология, с сильной, растущей и развивающейся экосистемой библиотек, фреймворков и различных инструментов разработки. Для этого нам нужно преодолеть наши “рельсовые” привычки, а это не легко и займет некоторое время. Пример такого rails-синдрома — использование ORM, в частности, Active Record. Это стало таким жестким стандартом, что у многих людей есть серьезные проблемы с пониманием того, как использовать альтернативы. Это, конечно, частично из-за нехватки информации и потому что альтернативные решения все еще относительно молоды. Но я уверен, что даже если появятся хорошие ресурсы, разработчики будут считать альтернативные подходы сложными, потому что использовать их будет непривычно. Это немного похоже на ситуацию в PHP, когда сообщество начало применять хорошие патерны проектирования, но потребовалось некоторое время, чтобы объяснить всем вещи типа «не подключайтесь к базе данных и не получайте записи во view, хорошо?». Ситуация у нас, конечно, сильно лучше, чем у PHP тогда, но я вижу аналогию. Так что да, избавление от вредных привычек и продолжение эволюции экосистемы — именно те задачи, которые нам нужно сейчас решить. Интересно, что в сообществе есть много людей, которые полностью не согласятся со мной, и это хорошо: сообщество Ruby достаточно велико, чтобы иметь много разных мнений. Важно иметь разнообразную экосистему, до сих пор мы были в основном монокультурой, собранной вокруг Rails. Это особенно заметно, если посмотреть на вакансии, которые есть на рынке.
На твой взгляд, какова самая важная задача, которая должна быть исправлена / реализована в MRI, чтобы сделать Ruby намного лучше, чем сейчас?
Мой ответ не оригинален — улучшить concurrency. Я бы хотел прогресса в унификации proc / lambda / method-object, а еще новые фичи, например поддержку композитных procs. Если бы функции в Ruby стали основными строительными блоками — это было бы потрясающе. Я думаю, что Ruby должен более четко раскрывать свою функциональную сторону, я считаю ее чрезвычайно полезной, но трудно убедить в ее важности некоторых людей, поскольку они застряли в парадигме OOП.
Как стек dry-* изменился по сравнению с его первоначальной идей? Что изменилось во время его разработки? Почему это произошло?
Изначальная идея состояла в том, чтобы создать набор небольших библиотек, которые можно было бы использовать для создания больших вещей, но в итоге у нас вышло большое количество библиотек, от самых маленьких, до относительно больших и сложных гемов. Причина, по которой это произошло, довольно проста — некоторые концепты оказались на поверку хорошими идеями, и они по-прежнему вписываются в философию dry-rb, заключающуюся прежде всего в том, чтобы иметь набор легко компонуемых библиотек, которые не навязывают конкретную структуру приложения. Некоторые из этих идей превратились в dry-rb гемы, такие как dry-system или dry-validation. Оба этих гема достаточно большие (при условии, что вы считаете, что 2k CLOC — большая библиотека, я — считаю).
Приходите в эту субботу на RailsClub, чтобы познакомиться с Петром!
Традиционно благодарим прекрасные компании, которые поддерживают конференцию. Наш генеральный партнер:
Toptal — распределенная мировая биржа, к которой уже присоединились самые талантливые разработчики со всего мира. Топтал создан инженерами, чтобы помогать компаниям ускоряться и масштабироваться.
Будьте в курсе наших новостей, подписавшись на рассылку на сайте railsclub.ru, и следите за обновлениями:
RailsClub.ru
twitter.com/railsclub_ru
facebook.com/railsclub
Как ты считаешь, какая самая большая задача сейчас стоит перед Ruby и RoR сообществом?
Самая важная задача для нас заключается в том, чтобы доказать, что стоит выбирать Ruby для новых проектов, что это жизнеспособная технология, с сильной, растущей и развивающейся экосистемой библиотек, фреймворков и различных инструментов разработки. Для этого нам нужно преодолеть наши “рельсовые” привычки, а это не легко и займет некоторое время. Пример такого rails-синдрома — использование ORM, в частности, Active Record. Это стало таким жестким стандартом, что у многих людей есть серьезные проблемы с пониманием того, как использовать альтернативы. Это, конечно, частично из-за нехватки информации и потому что альтернативные решения все еще относительно молоды. Но я уверен, что даже если появятся хорошие ресурсы, разработчики будут считать альтернативные подходы сложными, потому что использовать их будет непривычно. Это немного похоже на ситуацию в PHP, когда сообщество начало применять хорошие патерны проектирования, но потребовалось некоторое время, чтобы объяснить всем вещи типа «не подключайтесь к базе данных и не получайте записи во view, хорошо?». Ситуация у нас, конечно, сильно лучше, чем у PHP тогда, но я вижу аналогию. Так что да, избавление от вредных привычек и продолжение эволюции экосистемы — именно те задачи, которые нам нужно сейчас решить. Интересно, что в сообществе есть много людей, которые полностью не согласятся со мной, и это хорошо: сообщество Ruby достаточно велико, чтобы иметь много разных мнений. Важно иметь разнообразную экосистему, до сих пор мы были в основном монокультурой, собранной вокруг Rails. Это особенно заметно, если посмотреть на вакансии, которые есть на рынке.
На твой взгляд, какова самая важная задача, которая должна быть исправлена / реализована в MRI, чтобы сделать Ruby намного лучше, чем сейчас?
Мой ответ не оригинален — улучшить concurrency. Я бы хотел прогресса в унификации proc / lambda / method-object, а еще новые фичи, например поддержку композитных procs. Если бы функции в Ruby стали основными строительными блоками — это было бы потрясающе. Я думаю, что Ruby должен более четко раскрывать свою функциональную сторону, я считаю ее чрезвычайно полезной, но трудно убедить в ее важности некоторых людей, поскольку они застряли в парадигме OOП.
Как стек dry-* изменился по сравнению с его первоначальной идей? Что изменилось во время его разработки? Почему это произошло?
Изначальная идея состояла в том, чтобы создать набор небольших библиотек, которые можно было бы использовать для создания больших вещей, но в итоге у нас вышло большое количество библиотек, от самых маленьких, до относительно больших и сложных гемов. Причина, по которой это произошло, довольно проста — некоторые концепты оказались на поверку хорошими идеями, и они по-прежнему вписываются в философию dry-rb, заключающуюся прежде всего в том, чтобы иметь набор легко компонуемых библиотек, которые не навязывают конкретную структуру приложения. Некоторые из этих идей превратились в dry-rb гемы, такие как dry-system или dry-validation. Оба этих гема достаточно большие (при условии, что вы считаете, что 2k CLOC — большая библиотека, я — считаю).
Приходите в эту субботу на RailsClub, чтобы познакомиться с Петром!
Традиционно благодарим прекрасные компании, которые поддерживают конференцию. Наш генеральный партнер:
Toptal — распределенная мировая биржа, к которой уже присоединились самые талантливые разработчики со всего мира. Топтал создан инженерами, чтобы помогать компаниям ускоряться и масштабироваться.
Будьте в курсе наших новостей, подписавшись на рассылку на сайте railsclub.ru, и следите за обновлениями:
RailsClub.ru
twitter.com/railsclub_ru
facebook.com/railsclub