Этого треда уже нет.
Это копия, сохраненная 5 мая 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 5 мая 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
СЛОУНОВОСТИ
Ruby 2.6 introduces an initial implementation of JIT (Just-in-time) compiler
Ruby 2.5 has removed top level constant lookup
Ruby 2.5 requires pp by default
Ruby 2.5 added lazy proc allocation for block parameters
Ruby 2.4 unifies Fixnum and Bignum into Integer
Предыдущий тред: https://2ch.hk/pr/res/1272457.html (
М)
ИЗУЧЕНИЕ ЯЗЫКА
Q: C чего мне начать, чтобы стать рубистом?
A: Отличным началом будет Programming Ruby (The Pragmatic Programmers Guide), читать Eloquent Ruby и The Well Grounded Rubyist после прочтения первой толку особо не даст, одни и те же вещи, дальше читаем Ruby Way, затем познаем метапрограммирование с Metaprogramming Ruby.
А дальше открываем Ruby cookbook 2015 года, Пишем свой код во время чтения.
Q: Следующий уровень, продвинутые книги по руби:
A: Confident Ruby by Avdi Grimm | Practical Object-Oriented Design in Ruby
Refactoring Ruby Edition | Ruby Under a Microscope
Q: Онлайн курсы чтобы попробовать/вкатиться:
A: http://tryruby.org/levels/1/challenges/0/ | https://rubymonk.com/
http://www.codewars.com/?language=ruby | http://rubykoans.com
Q: Какой gem посмотреть, чтобы понять, как писать код?
A: Лучше всего посмотреть небольшие gem'ы вроде cancancan, pundit, camping.
Еще можешь полистать на гитхабе гемы с нарастающей популярностю (там еще нет тысяч строк, и тебе будет легче понять): https://github.com/trending?l=ruby
Q: Хорошие практики по руби и рельсам?
A: Обязательно стайлгайды (как оформлять код):
https://github.com/bbatsov/ruby-style-guide
https://github.com/JuanitoFatas/fast-ruby
https://github.com/bbatsov/rails-style-guide
Руководства "для чайников":
https://www.railstutorial.org/book [en]
http://www.theodinproject.com/ruby-on-rails [en] | http://codenamecrud.ru/ [ru]
Q: Документация по стандартным библиотекам руби и рельс:
A: http://ruby-doc.org/ | http://api.rubyonrails.org
http://guides.rubyonrails.org | http://ruby.railstutorial.org
Q: Можно ли на руби писать нативные GUI, мобильные приложения, игры?
A: Нет.
Q: Что ещё изучить?
A: Английский, git, linux. Паттерны. Один из часто используемых - Service Object.
СРЕДА РАЗРАБОТКИ
Q: Как установить разные версии рубей?
A: https://rvm.io | https://github.com/sstephenson/rbenv
Ruby 2.6 introduces an initial implementation of JIT (Just-in-time) compiler
Ruby 2.5 has removed top level constant lookup
Ruby 2.5 requires pp by default
Ruby 2.5 added lazy proc allocation for block parameters
Ruby 2.4 unifies Fixnum and Bignum into Integer
Предыдущий тред: https://2ch.hk/pr/res/1272457.html (
М)ИЗУЧЕНИЕ ЯЗЫКА
Q: C чего мне начать, чтобы стать рубистом?
A: Отличным началом будет Programming Ruby (The Pragmatic Programmers Guide), читать Eloquent Ruby и The Well Grounded Rubyist после прочтения первой толку особо не даст, одни и те же вещи, дальше читаем Ruby Way, затем познаем метапрограммирование с Metaprogramming Ruby.
А дальше открываем Ruby cookbook 2015 года, Пишем свой код во время чтения.
Q: Следующий уровень, продвинутые книги по руби:
A: Confident Ruby by Avdi Grimm | Practical Object-Oriented Design in Ruby
Refactoring Ruby Edition | Ruby Under a Microscope
Q: Онлайн курсы чтобы попробовать/вкатиться:
A: http://tryruby.org/levels/1/challenges/0/ | https://rubymonk.com/
http://www.codewars.com/?language=ruby | http://rubykoans.com
Q: Какой gem посмотреть, чтобы понять, как писать код?
A: Лучше всего посмотреть небольшие gem'ы вроде cancancan, pundit, camping.
Еще можешь полистать на гитхабе гемы с нарастающей популярностю (там еще нет тысяч строк, и тебе будет легче понять): https://github.com/trending?l=ruby
Q: Хорошие практики по руби и рельсам?
A: Обязательно стайлгайды (как оформлять код):
https://github.com/bbatsov/ruby-style-guide
https://github.com/JuanitoFatas/fast-ruby
https://github.com/bbatsov/rails-style-guide
Руководства "для чайников":
https://www.railstutorial.org/book [en]
http://www.theodinproject.com/ruby-on-rails [en] | http://codenamecrud.ru/ [ru]
Q: Документация по стандартным библиотекам руби и рельс:
A: http://ruby-doc.org/ | http://api.rubyonrails.org
http://guides.rubyonrails.org | http://ruby.railstutorial.org
Q: Можно ли на руби писать нативные GUI, мобильные приложения, игры?
A: Нет.
Q: Что ещё изучить?
A: Английский, git, linux. Паттерны. Один из часто используемых - Service Object.
СРЕДА РАЗРАБОТКИ
Q: Как установить разные версии рубей?
A: https://rvm.io | https://github.com/sstephenson/rbenv
в шапку надо было добавить скорый приход РоР 6
Тесты
Вот скажите, где золотая пуля?
В рельсах есть так называемые фикстуры - пишешь в ямле объекты и используешь их в своих тестах.
Еще есть FactoryBot - описываешь так называемую фабрику и она при помощи лаконичного вызова генерит объекты.
Практически безапеляционно побеждают фабрики ибо позволяют генерить любые наборы, под нужную ситуацию, что было бы просто нереально захардкодить фикстурами.
Ок.
Но есть задачи со сложной предметной областью: когда у моделей/проекта есть жизненный цикл с множеством состояний и ветвистый процесс. И чтобы протестировать программу в конкретной точке, недостаточно просто сгенерить несколько объектов. А нужен весьма большой сетап из нескольких моделей (не двух и не трех), со взаимозависимыми (!) стейтами и с кучей подчиненных объектов.
Если это делать при помощи фабрик, то уже третья ассоциация становится адом. И это только иерархия, без учета количества объектов и свойств связанных объектов. Отдельная боль это валидации, ведь фабрики должны быть валидными очевидно нехуй держать валидации в моделях.
Каждый раз когда я попадаю в такую ситуацию, я охуеваю.
Вопрос - есть ли какая-либо практика для таких случаев, когда нужно тестировать сложные контексты в разных точках жизненного цикла?
PS
И еще один смежный вопрос. Вот в Рспеке есть стабы и запись типа allow_any_instance_of to_recieve... И оговорка, что вообще-то это прием для легаси кода, и этого надо избегать.
А как же избегать, если тестируемые процессы много от чего зависят. Ну например какой-нибудь сервис-обджект, который использует другой сервис-обджект, оба используют квери-обджекты и еще используют полиси-обджекты. Уже дохуя, хотя все примитивно. И мы хотим протестить наш SO. И чтобы не моделировать сложные контексты для этих вложенных сервис/квери/полиси-обджетов (ибо тестируем не их) мы берем их и стабаем с нужным результатом - чтобы получить нужную ситуацию.
А если не стабать, то как тогда? Dependency Injection? Но в таком случае наш объект помимо своих основных параметров должен принимать еще штук пять DI-инъекций. Код превратится во что-то неперевариваемое.
Вот скажите, где золотая пуля?
В рельсах есть так называемые фикстуры - пишешь в ямле объекты и используешь их в своих тестах.
Еще есть FactoryBot - описываешь так называемую фабрику и она при помощи лаконичного вызова генерит объекты.
Практически безапеляционно побеждают фабрики ибо позволяют генерить любые наборы, под нужную ситуацию, что было бы просто нереально захардкодить фикстурами.
Ок.
Но есть задачи со сложной предметной областью: когда у моделей/проекта есть жизненный цикл с множеством состояний и ветвистый процесс. И чтобы протестировать программу в конкретной точке, недостаточно просто сгенерить несколько объектов. А нужен весьма большой сетап из нескольких моделей (не двух и не трех), со взаимозависимыми (!) стейтами и с кучей подчиненных объектов.
Если это делать при помощи фабрик, то уже третья ассоциация становится адом. И это только иерархия, без учета количества объектов и свойств связанных объектов. Отдельная боль это валидации, ведь фабрики должны быть валидными очевидно нехуй держать валидации в моделях.
Каждый раз когда я попадаю в такую ситуацию, я охуеваю.
Вопрос - есть ли какая-либо практика для таких случаев, когда нужно тестировать сложные контексты в разных точках жизненного цикла?
PS
И еще один смежный вопрос. Вот в Рспеке есть стабы и запись типа allow_any_instance_of to_recieve... И оговорка, что вообще-то это прием для легаси кода, и этого надо избегать.
А как же избегать, если тестируемые процессы много от чего зависят. Ну например какой-нибудь сервис-обджект, который использует другой сервис-обджект, оба используют квери-обджекты и еще используют полиси-обджекты. Уже дохуя, хотя все примитивно. И мы хотим протестить наш SO. И чтобы не моделировать сложные контексты для этих вложенных сервис/квери/полиси-обджетов (ибо тестируем не их) мы берем их и стабаем с нужным результатом - чтобы получить нужную ситуацию.
А если не стабать, то как тогда? Dependency Injection? Но в таком случае наш объект помимо своих основных параметров должен принимать еще штук пять DI-инъекций. Код превратится во что-то неперевариваемое.
Тесты
Вот скажите, где золотая пуля?
В рельсах есть так называемые фикстуры - пишешь в ямле объекты и используешь их в своих тестах.
Еще есть FactoryBot - описываешь так называемую фабрику и она при помощи лаконичного вызова генерит объекты.
Практически безапеляционно побеждают фабрики ибо позволяют генерить любые наборы, под нужную ситуацию, что было бы просто нереально захардкодить фикстурами.
Ок.
Но есть задачи со сложной предметной областью: когда у моделей/проекта есть жизненный цикл с множеством состояний и ветвистый процесс. И чтобы протестировать программу в конкретной точке, недостаточно просто сгенерить несколько объектов. А нужен весьма большой сетап из нескольких моделей (не двух и не трех), со взаимозависимыми (!) стейтами и с кучей подчиненных объектов.
Если это делать при помощи фабрик, то уже третья ассоциация становится адом. И это только иерархия, без учета количества объектов и свойств связанных объектов. Отдельная боль это валидации, ведь фабрики должны быть валидными очевидно нехуй держать валидации в моделях.
Каждый раз когда я попадаю в такую ситуацию, я охуеваю.
Вопрос - есть ли какая-либо практика для таких случаев, когда нужно тестировать сложные контексты в разных точках жизненного цикла?
PS
И еще один смежный вопрос. Вот в Рспеке есть стабы и запись типа allow_any_instance_of to_recieve... И оговорка, что вообще-то это прием для легаси кода, и этого надо избегать.
А как же избегать, если тестируемые процессы много от чего зависят. Ну например какой-нибудь сервис-обджект, который использует другой сервис-обджект, оба используют квери-обджекты и еще используют полиси-обджекты. Уже дохуя, хотя все примитивно. И мы хотим протестить наш SO. И чтобы не моделировать сложные контексты для этих вложенных сервис/квери/полиси-обджетов (ибо тестируем не их) мы берем их и стабаем с нужным результатом - чтобы получить нужную ситуацию.
А если не стабать, то как тогда? Dependency Injection? Но в таком случае наш объект помимо своих основных параметров должен принимать еще штук пять DI-инъекций. Код превратится во что-то неперевариваемое.
Вот скажите, где золотая пуля?
В рельсах есть так называемые фикстуры - пишешь в ямле объекты и используешь их в своих тестах.
Еще есть FactoryBot - описываешь так называемую фабрику и она при помощи лаконичного вызова генерит объекты.
Практически безапеляционно побеждают фабрики ибо позволяют генерить любые наборы, под нужную ситуацию, что было бы просто нереально захардкодить фикстурами.
Ок.
Но есть задачи со сложной предметной областью: когда у моделей/проекта есть жизненный цикл с множеством состояний и ветвистый процесс. И чтобы протестировать программу в конкретной точке, недостаточно просто сгенерить несколько объектов. А нужен весьма большой сетап из нескольких моделей (не двух и не трех), со взаимозависимыми (!) стейтами и с кучей подчиненных объектов.
Если это делать при помощи фабрик, то уже третья ассоциация становится адом. И это только иерархия, без учета количества объектов и свойств связанных объектов. Отдельная боль это валидации, ведь фабрики должны быть валидными очевидно нехуй держать валидации в моделях.
Каждый раз когда я попадаю в такую ситуацию, я охуеваю.
Вопрос - есть ли какая-либо практика для таких случаев, когда нужно тестировать сложные контексты в разных точках жизненного цикла?
PS
И еще один смежный вопрос. Вот в Рспеке есть стабы и запись типа allow_any_instance_of to_recieve... И оговорка, что вообще-то это прием для легаси кода, и этого надо избегать.
А как же избегать, если тестируемые процессы много от чего зависят. Ну например какой-нибудь сервис-обджект, который использует другой сервис-обджект, оба используют квери-обджекты и еще используют полиси-обджекты. Уже дохуя, хотя все примитивно. И мы хотим протестить наш SO. И чтобы не моделировать сложные контексты для этих вложенных сервис/квери/полиси-обджетов (ибо тестируем не их) мы берем их и стабаем с нужным результатом - чтобы получить нужную ситуацию.
А если не стабать, то как тогда? Dependency Injection? Но в таком случае наш объект помимо своих основных параметров должен принимать еще штук пять DI-инъекций. Код превратится во что-то неперевариваемое.
>>24696
В текущем проекте пишем методы которые создают объекты/добавляют стабы и вызываем их потом в before. Причем может быть много небольших методов создающих только небольшие части контекста и на их основе уже строятся более сложные методы. Все эти методы принимают один хеш с настройками, если метод составной, то он соответственно, передает этот хеш ниже. Не то что бы идеальное решение, но в проекте уже 10к+ тестов и пока полет нормальный.
DI в руби не нужен, я считаю, это не джава, где все гвоздями прибито. По-моему это они на волне хайпа DI года 3 назад решили написать, что allow это плохо. А так сколько я не работал, везде в тестах были allow, использование DI в продакшене проектах не видел ни разу. Хотя злоупотреблять allow тоже не стоит, а то вполне могут получится тесты, которые только стабы одни и тестируют, а не реальный код.
>Вопрос - есть ли какая-либо практика для таких случаев, когда нужно тестировать сложные контексты в разных точках жизненного цикла?
В текущем проекте пишем методы которые создают объекты/добавляют стабы и вызываем их потом в before. Причем может быть много небольших методов создающих только небольшие части контекста и на их основе уже строятся более сложные методы. Все эти методы принимают один хеш с настройками, если метод составной, то он соответственно, передает этот хеш ниже. Не то что бы идеальное решение, но в проекте уже 10к+ тестов и пока полет нормальный.
>А если не стабать, то как тогда? Dependency Injection?
DI в руби не нужен, я считаю, это не джава, где все гвоздями прибито. По-моему это они на волне хайпа DI года 3 назад решили написать, что allow это плохо. А так сколько я не работал, везде в тестах были allow, использование DI в продакшене проектах не видел ни разу. Хотя злоупотреблять allow тоже не стоит, а то вполне могут получится тесты, которые только стабы одни и тестируют, а не реальный код.
>>24910
Я на django никогда не писал, но слышал, что батареек в нем меньше, чем в рельсах. И спрашивается зачем он тогда нужен? Если уж отказываться от батареек и писать не на руби, то лучше взять сразу какой-нибудь kotlin со спринг бутом или ktor, а не такой же тормозной питон.
Я на django никогда не писал, но слышал, что батареек в нем меньше, чем в рельсах. И спрашивается зачем он тогда нужен? Если уж отказываться от батареек и писать не на руби, то лучше взять сразу какой-нибудь kotlin со спринг бутом или ktor, а не такой же тормозной питон.
>>25163
Там кстати нужно включить настройку, какую не помню, чтобы проверялась сигнатура, то есть чтобы проверялось существование застабаных методов.
>злоупотреблять allow тоже не стоит, а то вполне могут получится тесты, которые только стабы одни и тестируют
Там кстати нужно включить настройку, какую не помню, чтобы проверялась сигнатура, то есть чтобы проверялось существование застабаных методов.
>>25171
Зато вакансий причем годных дохуя. А по рельсам уже второй год висят одни и те же 15 вакансий на легаси-проекты аля "доработка функционала, фиксинг багов".
Зато вакансий причем годных дохуя. А по рельсам уже второй год висят одни и те же 15 вакансий на легаси-проекты аля "доработка функционала, фиксинг багов".
>>25295
Вакансии на питоне могут неплохие на МЛ быть, а веб-параша, она и есть веб-параша. Скинь парочку что ли, а то я проскролил первую страницу hh с поиском по django и ничего годного не нашел.
Вакансии на питоне могут неплохие на МЛ быть, а веб-параша, она и есть веб-параша. Скинь парочку что ли, а то я проскролил первую страницу hh с поиском по django и ничего годного не нашел.
>>25418
Просто зашел на фрилансим, смотрю что есть по руби - ну буквально задачи четыре. Потом смотрю питон - а там несколько страниц. Ну я и экстраполировал это на вакансии.
Да и так я частенько видел годноту на питоне. Мапс.ме относительно недавно видел, например, и вообще мейловые вакансии часто встречал.
Кстати, у меня такое ощущение, что в питере больше рубишных вакансий, вам не кажется?
Просто зашел на фрилансим, смотрю что есть по руби - ну буквально задачи четыре. Потом смотрю питон - а там несколько страниц. Ну я и экстраполировал это на вакансии.
Да и так я частенько видел годноту на питоне. Мапс.ме относительно недавно видел, например, и вообще мейловые вакансии часто встречал.
Кстати, у меня такое ощущение, что в питере больше рубишных вакансий, вам не кажется?
Посоны, а что случилось с rubyjobs.ru? Я раньше там мониторил буржуйские вакансии для вань, а теперь хуй.
>>25295
вопрос был про техническую составляющую
вопрос был про техническую составляющую
>>25427
Так-то да, русскоязычный фриланс на руби мертв, но он всегда был мертв, хочешь фрилансить на руби, идешь на апворк.
У нас, наверное, разное понятие годноты, хотя в мапс.ме может быть и неплохо. Но вообще вся годнота требует знаний в релевантной области, ЯП знать там зачастую достаточно на поверхностном уровне.
Нет, в ДС явно больше.
>фрилансим
Так-то да, русскоязычный фриланс на руби мертв, но он всегда был мертв, хочешь фрилансить на руби, идешь на апворк.
>Мапс.ме относительно недавно видел, например, и вообще мейловые вакансии часто встречал.
У нас, наверное, разное понятие годноты, хотя в мапс.ме может быть и неплохо. Но вообще вся годнота требует знаний в релевантной области, ЯП знать там зачастую достаточно на поверхностном уровне.
>Кстати, у меня такое ощущение, что в питере больше рубишных вакансий, вам не кажется?
Нет, в ДС явно больше.
мертвый тред мертвого языка
>>25430
Переехал в телеграмм. Ищи там одноимённый канал.
Переехал в телеграмм. Ищи там одноимённый канал.
Я сам не местный, короче рубибои объясните, как вы делаете что в терминале процент загрузки например пишется в этой же строчке а не в новой. Типа
$ update
modulname updating 98% и проценты как бы в одной строчке меняются
а не
$ update
modulname updating 95%
modulname updating 96%
modulname updating 97%
то есть не пишет постоянно в новой строчке
$ update
modulname updating 98% и проценты как бы в одной строчке меняются
а не
$ update
modulname updating 95%
modulname updating 96%
modulname updating 97%
то есть не пишет постоянно в новой строчке
>>25671
Кешируется. Делай или STDOUT.flush или STDOUT.sync = true. Но убедись, что понимаешь последствия второго варианта перед тем как его использовать.
Кешируется. Делай или STDOUT.flush или STDOUT.sync = true. Но убедись, что понимаешь последствия второго варианта перед тем как его использовать.
>>25767
stdout это просто глобально доступный инстанс класса IO, можешь его доки посмотреть https://devdocs.io/ruby~2.5/io
stdout это просто глобально доступный инстанс класса IO, можешь его доки посмотреть https://devdocs.io/ruby~2.5/io
Хочу вкатиться в Ruby. Какой стек технологий и на каком уровне необходимо освоить, чтобы взяли на работу трейни/джуном?
>>25810
Рандомный (стандартный стек осваивай: реальса реакт скуль линукс охапка популярных гемов) стек осваивай, руби джун вакансий настолько мало, что это чистый рандом в россии.
Как вариант набери опыта в PHP-конторе.
Рандомный (стандартный стек осваивай: реальса реакт скуль линукс охапка популярных гемов) стек осваивай, руби джун вакансий настолько мало, что это чистый рандом в россии.
Как вариант набери опыта в PHP-конторе.
>>25810
руби удел фанатов
руби удел фанатов
Посоветуйте книгу для быстрого изучения основ языка. Лучше на русском, но можно на английском.
Нужно для экзамена в университете.
Нужно для экзамена в университете.
>>25984
Согласен
Курс был рассчитан на изучение основ веб программирования и Ruby on Rails
По итогу было прочитано много материала по рельсам, но есть непонимание самого языка, поэтому реквестирую книгу по чистому руби без упоминания рельс.
Согласен
Курс был рассчитан на изучение основ веб программирования и Ruby on Rails
По итогу было прочитано много материала по рельсам, но есть непонимание самого языка, поэтому реквестирую книгу по чистому руби без упоминания рельс.
>>25989
Russ Olsen, Eloquent Ruby
Russ Olsen, Eloquent Ruby
Эх, как вы здесь, без меня потомки? Даже старый файлик с перекататом сохранился у меня.
1. C чего мне начать, чтобы стать рубистом?
Отличным началом будет Programming Ruby (The Pragmatic Programmers Guide), читать Eloquent Ruby и The Well Grounded Rubyist после прочтения первой толку особо не даст, одни и теже вещи, дальше читаем Ruby Way, затем познаем метапрограммирование с Metaprogramming Ruby. А дальше открываем Ruby cookbook 2015 года, Пишем свой код во время чтения.
Следующий уровень, продвинутые книги по руби:
Confident Ruby by Avdi Grimm
Practical Object-Oriented Design in Ruby
Refactoring Ruby Edition
Ruby Under a Microscope для любителей залезть под капот.
Документация по стандартным библиотекам http://ruby-doc.org/
Можно пройти руби онлайн - http://tryruby.org/levels/1/challenges/0
И ещё раз онлайн: http://www.codewars.com/?language=ruby
Не веришь в свои силы? Прочитал уже книжек много и силы свои хочешь познать, сделай - http://rubykoans.com
И вот еще https://rubymonk.com/ - Матц одобряет.
2. Какой gem посмотреть, чтобы понять, как писать код?
Лучше всего посмотреть небольшие gem'ы вроде cancancan, pundit, camping.
А еще можешь полистать на гитхабе гемы с нарастающей популярностю.
https://github.com/trending?l=ruby
Там еще нет тысяч строк, и тебе будет легче понять.
3. Есть ли GUI для руби?
Да. Есть обвязки к Qt, GTK, wxWidgets, Shoes, fxruby (одобренный).
4. Можно ли писать на руби мобильное ПО?
Да. Для iOS есть RubyMotion терпимого качества, для Android - лагающий и падающий, но всеми силами развивающийся ruboto. Для WinPhone до сих пор ничего не завезли.
5. Как установить разные версии рубей?
Легко и просто: https://github.com/sstephenson/rbenv
И это тоже, легко и просто: https://rvm.io
6. Что почитать по рельсам?
http://guides.rubyonrails.org
http://ruby.railstutorial.org
API: http://api.rubyonrails.org
Прекрасные туториалы в стиле for dummies - http://www.theodinproject.com/ruby-on-rails , а вот тут все тоже, но на русском http://codenamecrud.ru/
Классический вводный туториал, где делается с нуля клон твиттера, для новичков в rails самое то - https://www.railstutorial.org/book
Для дотошных читателей есть The Rails 4 Way.
7. Хорошие практики по руби и рельсам?
Читаем Rails AntiPatterns, смотрим Rails Best Practices, также неплохо посмотреть Rails Recipes.
Почитайте еще Grimm A. - Objects on Rails
Еще продвинутое чтиво - http://tutorials.jumpstartlab.com/
8. Ruby/Rails блоги, рассылки и твитторы
IRC каналы на FreeNode: #ruby, #ruby-core, #RubyOnRails, #rails (не очень активен).
Твитторы @rails, @dhh, @yukihiro_matz, @wycats, @tenderlove
Рассылки ruby-core, rails-core, rails-talk
Подкасты:
- http://rubyrogues.com
- http://ruby5.envylabs.com
Скринкасты:
- http://railscasts.com
- https://peepcode.com
- https://www.destroyallsoftware.com
- http://railsforzombies.com
Блоги:
- rubyflow.com - каждый день новости, новые библиотеки, обновления, все дела.
- rubysource.com - читаем интервью, хорошие практики, и безумные сравнения упоротого дибила-индуса на самом деле их пропускаем
- rubyinside.com - новости, туториалы.
- rubyweekly.com
- http://37signals.com/svn
- http://yehudakatz.com
- http://afreshcup.com
9. Я не могу в английский, что делать, анон?
Идти учить английский, без него тут делать нечего.
10. Есть ли у руби русское коммьюнити?
Нет. Вернее есть, но оно протухло и там полно людей у которых чсв высоко.
Яркий пример -ru$_Cby ANUSconference.jabber PUNCTUMrRnZu
А еще есть русская слак конфа - https://russiandevs.slack.com она общая, но есть очень активный руби канал.
Так же русская гугл группа, активная - https://groups.google.com/forum/#!forum/ror2ru
Еще вот - https://onrails.club/
11. Какие гемы стоит знать?
capybara, rack, rspec, devise, cancancan, simple_form, solr, sinatra, тысячи их.
Поиск гемов https://www.ruby-toolbox.com
12. Зачем нужны тесты и как их писать?
http://rusrails.ru/a-guide-to-testing-rails-applications
http://habrahabr.ru/post/163597/
Вместо этого можно прочитать классную книгу Everyday Rails Testing
13. Где можно задать глупые и не очень вопросы?
- здесь
- stackoverflow.com
- тематические slack-конфы
- а вообще, гугли, с вероятностью в 90% ответ на твой вопрос уже висит на stackoverflow.
14. Как фокнуть\сделать фичу\исправить баг, сложно ли это?
Нет, не сложно. На rubyflow появляется много новостей с реализацией новой библиотеки, вы можете сделать тесты, фичу для него, старые либы также обрастают багами, улучшайте их! пишите код.
15. В чём писать код?
Atom, Brackets, Sublime Text, TextMate, Vim, GNU Emacs. Для особо упоротых энтерпрайз-макак есть rubymine, плагины к эклипс и нетбинс.
16. Можно ли писать на руби с под windows?
Можно, но придется обрасти костылями в виде виртуальной машины, придется сходу разбираться с Vagrant и многим другим. Чем дальше ты продвигаешься, тем ближе становится ясно, что пора перекатываться на linux/mac
17. Руби язык одного фреймворка?
Есть еще Sinatra, Hanami (ранее Lotus), Volt, Grape, отличные штуки для DevOps - Chef, Puppet и годные генераторы для бложиков - Jekyll, Middleman, всё это активно используется в продакшене
18. Можно ли делать игры на Ruby?
Можно, но не нужно. Гем Gosu.
19. Ютуб каналы
Youtube driven development...
Вот тебе пара каналов, но никому не говори что учишься по видео.
https://www.youtube.com/channel/UCIQmhQxCvLHRr3Beku77tww/videos
https://www.youtube.com/channel/UCfWZwsP8trUy5uHJg8gcGIQ
https://www.youtube.com/channel/UCSI77lJlzlCFPLdV1RSAoYQ
https://www.youtube.com/channel/UCPIyDzf1vwWc8EQJGUX-vYw - тут на ру$$ком даже.
20. Как и где искать работу?
Легко и просто - http://rubyjobs.ru/
Не так просто - https://upwork.com/
Еще вконтакте есть группы по руби/рельсам, там иногда постят вакансии. Еще в русской гугл группе постят вакансии. Новичку будет сложно, но возможно.
TODO лист для ньюфагов:
И так, ты поставил руби, уже сгенерировал свой первый проект rails new pidaras
Начни уже с платинового пути, блог >> клон твиттера >> своя имейджборда >> свой гем >> дальше сам придумаешь.
Рекомендации:
1. Для блога, создать роли, Админ, Пользователь (можно использовать паттерн form object). Прикрутить лайки, комментарии.
2. По твиттеру, следуя гайду Хартла, пиши все то что он предлагает в качестве доп. заданий, например оповещение по нику (@eblan: привет)
3. По имиджборде: воссоздать по возможности полный функционал, в этом случае придется ознакомится с javascript/jquery/coffeescript, но тебе так или иначе придется. Еще хорошей фичей будет использование background job и крон тасков (sidekiq, whenever), чтобы заполнять свою борду тредами и постами с другой борды, можно использовать api двача, чтобы вытягивать треды и посты - https://github.com/ID25/api_2ch
4. Не стесняемся постить свои репозитории, наши эксперты с радостью отревьювят вас.
После этого тебе будут нужны паттерны, без них твой код превратится в говно. Один из часто используемых - Service Object.
https://netguru.co/blog/service-objects-in-rails-will-help - о сервисах
Еще паттернов - https://robots.thoughtbot.com/back-to-basics-solid
Но самый читаемый код, как и следовало ожидать, даёт функциональное программирование. Начни отсюда:
http://www.sitepoint.com/functional-programming-techniques-with-ruby-part-i/
http://www.sitepoint.com/functional-programming-techniques-with-ruby-part-ii/
http://www.sitepoint.com/functional-programming-techniques-with-ruby-part-iii/
http://www.sitepoint.com/functional-programming-pure-functions/
http://www.sitepoint.com/functional-programming-ruby-value-objects/
Только не переборщи. Руби - не функциональный язык, и иногда такой код может работать медленней.
Прочитал? Теперь рефактори то, что уже написал. И не забывай покрывать тестами.
Хорошим финалом будет деплой, это пожалуй самое болезненное, и ничего общего с деплоем на heroku, где тыц тыц и готово. Придется поковыряться со смежными вещами и узнать много нового, уже устоявшийся гем для таких дел - Capistrano.
Не забывайте спрашивать у анонасов вопросы, код лучше показывать через gist или pastebin с подсветочкой.
Ну, а мы открываем очередной Ruby Thread.
1. C чего мне начать, чтобы стать рубистом?
Отличным началом будет Programming Ruby (The Pragmatic Programmers Guide), читать Eloquent Ruby и The Well Grounded Rubyist после прочтения первой толку особо не даст, одни и теже вещи, дальше читаем Ruby Way, затем познаем метапрограммирование с Metaprogramming Ruby. А дальше открываем Ruby cookbook 2015 года, Пишем свой код во время чтения.
Следующий уровень, продвинутые книги по руби:
Confident Ruby by Avdi Grimm
Practical Object-Oriented Design in Ruby
Refactoring Ruby Edition
Ruby Under a Microscope для любителей залезть под капот.
Документация по стандартным библиотекам http://ruby-doc.org/
Можно пройти руби онлайн - http://tryruby.org/levels/1/challenges/0
И ещё раз онлайн: http://www.codewars.com/?language=ruby
Не веришь в свои силы? Прочитал уже книжек много и силы свои хочешь познать, сделай - http://rubykoans.com
И вот еще https://rubymonk.com/ - Матц одобряет.
2. Какой gem посмотреть, чтобы понять, как писать код?
Лучше всего посмотреть небольшие gem'ы вроде cancancan, pundit, camping.
А еще можешь полистать на гитхабе гемы с нарастающей популярностю.
https://github.com/trending?l=ruby
Там еще нет тысяч строк, и тебе будет легче понять.
3. Есть ли GUI для руби?
Да. Есть обвязки к Qt, GTK, wxWidgets, Shoes, fxruby (одобренный).
4. Можно ли писать на руби мобильное ПО?
Да. Для iOS есть RubyMotion терпимого качества, для Android - лагающий и падающий, но всеми силами развивающийся ruboto. Для WinPhone до сих пор ничего не завезли.
5. Как установить разные версии рубей?
Легко и просто: https://github.com/sstephenson/rbenv
И это тоже, легко и просто: https://rvm.io
6. Что почитать по рельсам?
http://guides.rubyonrails.org
http://ruby.railstutorial.org
API: http://api.rubyonrails.org
Прекрасные туториалы в стиле for dummies - http://www.theodinproject.com/ruby-on-rails , а вот тут все тоже, но на русском http://codenamecrud.ru/
Классический вводный туториал, где делается с нуля клон твиттера, для новичков в rails самое то - https://www.railstutorial.org/book
Для дотошных читателей есть The Rails 4 Way.
7. Хорошие практики по руби и рельсам?
Читаем Rails AntiPatterns, смотрим Rails Best Practices, также неплохо посмотреть Rails Recipes.
Почитайте еще Grimm A. - Objects on Rails
Еще продвинутое чтиво - http://tutorials.jumpstartlab.com/
8. Ruby/Rails блоги, рассылки и твитторы
IRC каналы на FreeNode: #ruby, #ruby-core, #RubyOnRails, #rails (не очень активен).
Твитторы @rails, @dhh, @yukihiro_matz, @wycats, @tenderlove
Рассылки ruby-core, rails-core, rails-talk
Подкасты:
- http://rubyrogues.com
- http://ruby5.envylabs.com
Скринкасты:
- http://railscasts.com
- https://peepcode.com
- https://www.destroyallsoftware.com
- http://railsforzombies.com
Блоги:
- rubyflow.com - каждый день новости, новые библиотеки, обновления, все дела.
- rubysource.com - читаем интервью, хорошие практики, и безумные сравнения упоротого дибила-индуса на самом деле их пропускаем
- rubyinside.com - новости, туториалы.
- rubyweekly.com
- http://37signals.com/svn
- http://yehudakatz.com
- http://afreshcup.com
9. Я не могу в английский, что делать, анон?
Идти учить английский, без него тут делать нечего.
10. Есть ли у руби русское коммьюнити?
Нет. Вернее есть, но оно протухло и там полно людей у которых чсв высоко.
Яркий пример -
А еще есть русская слак конфа - https://russiandevs.slack.com она общая, но есть очень активный руби канал.
Так же русская гугл группа, активная - https://groups.google.com/forum/#!forum/ror2ru
Еще вот - https://onrails.club/
11. Какие гемы стоит знать?
capybara, rack, rspec, devise, cancancan, simple_form, solr, sinatra, тысячи их.
Поиск гемов https://www.ruby-toolbox.com
12. Зачем нужны тесты и как их писать?
http://rusrails.ru/a-guide-to-testing-rails-applications
http://habrahabr.ru/post/163597/
Вместо этого можно прочитать классную книгу Everyday Rails Testing
13. Где можно задать глупые и не очень вопросы?
- здесь
- stackoverflow.com
- тематические slack-конфы
- а вообще, гугли, с вероятностью в 90% ответ на твой вопрос уже висит на stackoverflow.
14. Как фокнуть\сделать фичу\исправить баг, сложно ли это?
Нет, не сложно. На rubyflow появляется много новостей с реализацией новой библиотеки, вы можете сделать тесты, фичу для него, старые либы также обрастают багами, улучшайте их! пишите код.
15. В чём писать код?
Atom, Brackets, Sublime Text, TextMate, Vim, GNU Emacs. Для особо упоротых энтерпрайз-макак есть rubymine, плагины к эклипс и нетбинс.
16. Можно ли писать на руби с под windows?
Можно, но придется обрасти костылями в виде виртуальной машины, придется сходу разбираться с Vagrant и многим другим. Чем дальше ты продвигаешься, тем ближе становится ясно, что пора перекатываться на linux/mac
17. Руби язык одного фреймворка?
Есть еще Sinatra, Hanami (ранее Lotus), Volt, Grape, отличные штуки для DevOps - Chef, Puppet и годные генераторы для бложиков - Jekyll, Middleman, всё это активно используется в продакшене
18. Можно ли делать игры на Ruby?
Можно, но не нужно. Гем Gosu.
19. Ютуб каналы
Youtube driven development...
Вот тебе пара каналов, но никому не говори что учишься по видео.
https://www.youtube.com/channel/UCIQmhQxCvLHRr3Beku77tww/videos
https://www.youtube.com/channel/UCfWZwsP8trUy5uHJg8gcGIQ
https://www.youtube.com/channel/UCSI77lJlzlCFPLdV1RSAoYQ
https://www.youtube.com/channel/UCPIyDzf1vwWc8EQJGUX-vYw - тут на ру$$ком даже.
20. Как и где искать работу?
Легко и просто - http://rubyjobs.ru/
Не так просто - https://upwork.com/
Еще вконтакте есть группы по руби/рельсам, там иногда постят вакансии. Еще в русской гугл группе постят вакансии. Новичку будет сложно, но возможно.
TODO лист для ньюфагов:
И так, ты поставил руби, уже сгенерировал свой первый проект rails new pidaras
Начни уже с платинового пути, блог >> клон твиттера >> своя имейджборда >> свой гем >> дальше сам придумаешь.
Рекомендации:
1. Для блога, создать роли, Админ, Пользователь (можно использовать паттерн form object). Прикрутить лайки, комментарии.
2. По твиттеру, следуя гайду Хартла, пиши все то что он предлагает в качестве доп. заданий, например оповещение по нику (@eblan: привет)
3. По имиджборде: воссоздать по возможности полный функционал, в этом случае придется ознакомится с javascript/jquery/coffeescript, но тебе так или иначе придется. Еще хорошей фичей будет использование background job и крон тасков (sidekiq, whenever), чтобы заполнять свою борду тредами и постами с другой борды, можно использовать api двача, чтобы вытягивать треды и посты - https://github.com/ID25/api_2ch
4. Не стесняемся постить свои репозитории, наши эксперты с радостью отревьювят вас.
После этого тебе будут нужны паттерны, без них твой код превратится в говно. Один из часто используемых - Service Object.
https://netguru.co/blog/service-objects-in-rails-will-help - о сервисах
Еще паттернов - https://robots.thoughtbot.com/back-to-basics-solid
Но самый читаемый код, как и следовало ожидать, даёт функциональное программирование. Начни отсюда:
http://www.sitepoint.com/functional-programming-techniques-with-ruby-part-i/
http://www.sitepoint.com/functional-programming-techniques-with-ruby-part-ii/
http://www.sitepoint.com/functional-programming-techniques-with-ruby-part-iii/
http://www.sitepoint.com/functional-programming-pure-functions/
http://www.sitepoint.com/functional-programming-ruby-value-objects/
Только не переборщи. Руби - не функциональный язык, и иногда такой код может работать медленней.
Прочитал? Теперь рефактори то, что уже написал. И не забывай покрывать тестами.
Хорошим финалом будет деплой, это пожалуй самое болезненное, и ничего общего с деплоем на heroku, где тыц тыц и готово. Придется поковыряться со смежными вещами и узнать много нового, уже устоявшийся гем для таких дел - Capistrano.
Не забывайте спрашивать у анонасов вопросы, код лучше показывать через gist или pastebin с подсветочкой.
Ну, а мы открываем очередной Ruby Thread.
Эх, как вы здесь, без меня потомки? Даже старый файлик с перекататом сохранился у меня.
1. C чего мне начать, чтобы стать рубистом?
Отличным началом будет Programming Ruby (The Pragmatic Programmers Guide), читать Eloquent Ruby и The Well Grounded Rubyist после прочтения первой толку особо не даст, одни и теже вещи, дальше читаем Ruby Way, затем познаем метапрограммирование с Metaprogramming Ruby. А дальше открываем Ruby cookbook 2015 года, Пишем свой код во время чтения.
Следующий уровень, продвинутые книги по руби:
Confident Ruby by Avdi Grimm
Practical Object-Oriented Design in Ruby
Refactoring Ruby Edition
Ruby Under a Microscope для любителей залезть под капот.
Документация по стандартным библиотекам http://ruby-doc.org/
Можно пройти руби онлайн - http://tryruby.org/levels/1/challenges/0
И ещё раз онлайн: http://www.codewars.com/?language=ruby
Не веришь в свои силы? Прочитал уже книжек много и силы свои хочешь познать, сделай - http://rubykoans.com
И вот еще https://rubymonk.com/ - Матц одобряет.
2. Какой gem посмотреть, чтобы понять, как писать код?
Лучше всего посмотреть небольшие gem'ы вроде cancancan, pundit, camping.
А еще можешь полистать на гитхабе гемы с нарастающей популярностю.
https://github.com/trending?l=ruby
Там еще нет тысяч строк, и тебе будет легче понять.
3. Есть ли GUI для руби?
Да. Есть обвязки к Qt, GTK, wxWidgets, Shoes, fxruby (одобренный).
4. Можно ли писать на руби мобильное ПО?
Да. Для iOS есть RubyMotion терпимого качества, для Android - лагающий и падающий, но всеми силами развивающийся ruboto. Для WinPhone до сих пор ничего не завезли.
5. Как установить разные версии рубей?
Легко и просто: https://github.com/sstephenson/rbenv
И это тоже, легко и просто: https://rvm.io
6. Что почитать по рельсам?
http://guides.rubyonrails.org
http://ruby.railstutorial.org
API: http://api.rubyonrails.org
Прекрасные туториалы в стиле for dummies - http://www.theodinproject.com/ruby-on-rails , а вот тут все тоже, но на русском http://codenamecrud.ru/
Классический вводный туториал, где делается с нуля клон твиттера, для новичков в rails самое то - https://www.railstutorial.org/book
Для дотошных читателей есть The Rails 4 Way.
7. Хорошие практики по руби и рельсам?
Читаем Rails AntiPatterns, смотрим Rails Best Practices, также неплохо посмотреть Rails Recipes.
Почитайте еще Grimm A. - Objects on Rails
Еще продвинутое чтиво - http://tutorials.jumpstartlab.com/
8. Ruby/Rails блоги, рассылки и твитторы
IRC каналы на FreeNode: #ruby, #ruby-core, #RubyOnRails, #rails (не очень активен).
Твитторы @rails, @dhh, @yukihiro_matz, @wycats, @tenderlove
Рассылки ruby-core, rails-core, rails-talk
Подкасты:
- http://rubyrogues.com
- http://ruby5.envylabs.com
Скринкасты:
- http://railscasts.com
- https://peepcode.com
- https://www.destroyallsoftware.com
- http://railsforzombies.com
Блоги:
- rubyflow.com - каждый день новости, новые библиотеки, обновления, все дела.
- rubysource.com - читаем интервью, хорошие практики, и безумные сравнения упоротого дибила-индуса на самом деле их пропускаем
- rubyinside.com - новости, туториалы.
- rubyweekly.com
- http://37signals.com/svn
- http://yehudakatz.com
- http://afreshcup.com
9. Я не могу в английский, что делать, анон?
Идти учить английский, без него тут делать нечего.
10. Есть ли у руби русское коммьюнити?
Нет. Вернее есть, но оно протухло и там полно людей у которых чсв высоко.
Яркий пример -ru$_Cby ANUSconference.jabber PUNCTUMrRnZu
А еще есть русская слак конфа - https://russiandevs.slack.com она общая, но есть очень активный руби канал.
Так же русская гугл группа, активная - https://groups.google.com/forum/#!forum/ror2ru
Еще вот - https://onrails.club/
11. Какие гемы стоит знать?
capybara, rack, rspec, devise, cancancan, simple_form, solr, sinatra, тысячи их.
Поиск гемов https://www.ruby-toolbox.com
12. Зачем нужны тесты и как их писать?
http://rusrails.ru/a-guide-to-testing-rails-applications
http://habrahabr.ru/post/163597/
Вместо этого можно прочитать классную книгу Everyday Rails Testing
13. Где можно задать глупые и не очень вопросы?
- здесь
- stackoverflow.com
- тематические slack-конфы
- а вообще, гугли, с вероятностью в 90% ответ на твой вопрос уже висит на stackoverflow.
14. Как фокнуть\сделать фичу\исправить баг, сложно ли это?
Нет, не сложно. На rubyflow появляется много новостей с реализацией новой библиотеки, вы можете сделать тесты, фичу для него, старые либы также обрастают багами, улучшайте их! пишите код.
15. В чём писать код?
Atom, Brackets, Sublime Text, TextMate, Vim, GNU Emacs. Для особо упоротых энтерпрайз-макак есть rubymine, плагины к эклипс и нетбинс.
16. Можно ли писать на руби с под windows?
Можно, но придется обрасти костылями в виде виртуальной машины, придется сходу разбираться с Vagrant и многим другим. Чем дальше ты продвигаешься, тем ближе становится ясно, что пора перекатываться на linux/mac
17. Руби язык одного фреймворка?
Есть еще Sinatra, Hanami (ранее Lotus), Volt, Grape, отличные штуки для DevOps - Chef, Puppet и годные генераторы для бложиков - Jekyll, Middleman, всё это активно используется в продакшене
18. Можно ли делать игры на Ruby?
Можно, но не нужно. Гем Gosu.
19. Ютуб каналы
Youtube driven development...
Вот тебе пара каналов, но никому не говори что учишься по видео.
https://www.youtube.com/channel/UCIQmhQxCvLHRr3Beku77tww/videos
https://www.youtube.com/channel/UCfWZwsP8trUy5uHJg8gcGIQ
https://www.youtube.com/channel/UCSI77lJlzlCFPLdV1RSAoYQ
https://www.youtube.com/channel/UCPIyDzf1vwWc8EQJGUX-vYw - тут на ру$$ком даже.
20. Как и где искать работу?
Легко и просто - http://rubyjobs.ru/
Не так просто - https://upwork.com/
Еще вконтакте есть группы по руби/рельсам, там иногда постят вакансии. Еще в русской гугл группе постят вакансии. Новичку будет сложно, но возможно.
TODO лист для ньюфагов:
И так, ты поставил руби, уже сгенерировал свой первый проект rails new pidaras
Начни уже с платинового пути, блог >> клон твиттера >> своя имейджборда >> свой гем >> дальше сам придумаешь.
Рекомендации:
1. Для блога, создать роли, Админ, Пользователь (можно использовать паттерн form object). Прикрутить лайки, комментарии.
2. По твиттеру, следуя гайду Хартла, пиши все то что он предлагает в качестве доп. заданий, например оповещение по нику (@eblan: привет)
3. По имиджборде: воссоздать по возможности полный функционал, в этом случае придется ознакомится с javascript/jquery/coffeescript, но тебе так или иначе придется. Еще хорошей фичей будет использование background job и крон тасков (sidekiq, whenever), чтобы заполнять свою борду тредами и постами с другой борды, можно использовать api двача, чтобы вытягивать треды и посты - https://github.com/ID25/api_2ch
4. Не стесняемся постить свои репозитории, наши эксперты с радостью отревьювят вас.
После этого тебе будут нужны паттерны, без них твой код превратится в говно. Один из часто используемых - Service Object.
https://netguru.co/blog/service-objects-in-rails-will-help - о сервисах
Еще паттернов - https://robots.thoughtbot.com/back-to-basics-solid
Но самый читаемый код, как и следовало ожидать, даёт функциональное программирование. Начни отсюда:
http://www.sitepoint.com/functional-programming-techniques-with-ruby-part-i/
http://www.sitepoint.com/functional-programming-techniques-with-ruby-part-ii/
http://www.sitepoint.com/functional-programming-techniques-with-ruby-part-iii/
http://www.sitepoint.com/functional-programming-pure-functions/
http://www.sitepoint.com/functional-programming-ruby-value-objects/
Только не переборщи. Руби - не функциональный язык, и иногда такой код может работать медленней.
Прочитал? Теперь рефактори то, что уже написал. И не забывай покрывать тестами.
Хорошим финалом будет деплой, это пожалуй самое болезненное, и ничего общего с деплоем на heroku, где тыц тыц и готово. Придется поковыряться со смежными вещами и узнать много нового, уже устоявшийся гем для таких дел - Capistrano.
Не забывайте спрашивать у анонасов вопросы, код лучше показывать через gist или pastebin с подсветочкой.
Ну, а мы открываем очередной Ruby Thread.
1. C чего мне начать, чтобы стать рубистом?
Отличным началом будет Programming Ruby (The Pragmatic Programmers Guide), читать Eloquent Ruby и The Well Grounded Rubyist после прочтения первой толку особо не даст, одни и теже вещи, дальше читаем Ruby Way, затем познаем метапрограммирование с Metaprogramming Ruby. А дальше открываем Ruby cookbook 2015 года, Пишем свой код во время чтения.
Следующий уровень, продвинутые книги по руби:
Confident Ruby by Avdi Grimm
Practical Object-Oriented Design in Ruby
Refactoring Ruby Edition
Ruby Under a Microscope для любителей залезть под капот.
Документация по стандартным библиотекам http://ruby-doc.org/
Можно пройти руби онлайн - http://tryruby.org/levels/1/challenges/0
И ещё раз онлайн: http://www.codewars.com/?language=ruby
Не веришь в свои силы? Прочитал уже книжек много и силы свои хочешь познать, сделай - http://rubykoans.com
И вот еще https://rubymonk.com/ - Матц одобряет.
2. Какой gem посмотреть, чтобы понять, как писать код?
Лучше всего посмотреть небольшие gem'ы вроде cancancan, pundit, camping.
А еще можешь полистать на гитхабе гемы с нарастающей популярностю.
https://github.com/trending?l=ruby
Там еще нет тысяч строк, и тебе будет легче понять.
3. Есть ли GUI для руби?
Да. Есть обвязки к Qt, GTK, wxWidgets, Shoes, fxruby (одобренный).
4. Можно ли писать на руби мобильное ПО?
Да. Для iOS есть RubyMotion терпимого качества, для Android - лагающий и падающий, но всеми силами развивающийся ruboto. Для WinPhone до сих пор ничего не завезли.
5. Как установить разные версии рубей?
Легко и просто: https://github.com/sstephenson/rbenv
И это тоже, легко и просто: https://rvm.io
6. Что почитать по рельсам?
http://guides.rubyonrails.org
http://ruby.railstutorial.org
API: http://api.rubyonrails.org
Прекрасные туториалы в стиле for dummies - http://www.theodinproject.com/ruby-on-rails , а вот тут все тоже, но на русском http://codenamecrud.ru/
Классический вводный туториал, где делается с нуля клон твиттера, для новичков в rails самое то - https://www.railstutorial.org/book
Для дотошных читателей есть The Rails 4 Way.
7. Хорошие практики по руби и рельсам?
Читаем Rails AntiPatterns, смотрим Rails Best Practices, также неплохо посмотреть Rails Recipes.
Почитайте еще Grimm A. - Objects on Rails
Еще продвинутое чтиво - http://tutorials.jumpstartlab.com/
8. Ruby/Rails блоги, рассылки и твитторы
IRC каналы на FreeNode: #ruby, #ruby-core, #RubyOnRails, #rails (не очень активен).
Твитторы @rails, @dhh, @yukihiro_matz, @wycats, @tenderlove
Рассылки ruby-core, rails-core, rails-talk
Подкасты:
- http://rubyrogues.com
- http://ruby5.envylabs.com
Скринкасты:
- http://railscasts.com
- https://peepcode.com
- https://www.destroyallsoftware.com
- http://railsforzombies.com
Блоги:
- rubyflow.com - каждый день новости, новые библиотеки, обновления, все дела.
- rubysource.com - читаем интервью, хорошие практики, и безумные сравнения упоротого дибила-индуса на самом деле их пропускаем
- rubyinside.com - новости, туториалы.
- rubyweekly.com
- http://37signals.com/svn
- http://yehudakatz.com
- http://afreshcup.com
9. Я не могу в английский, что делать, анон?
Идти учить английский, без него тут делать нечего.
10. Есть ли у руби русское коммьюнити?
Нет. Вернее есть, но оно протухло и там полно людей у которых чсв высоко.
Яркий пример -
А еще есть русская слак конфа - https://russiandevs.slack.com она общая, но есть очень активный руби канал.
Так же русская гугл группа, активная - https://groups.google.com/forum/#!forum/ror2ru
Еще вот - https://onrails.club/
11. Какие гемы стоит знать?
capybara, rack, rspec, devise, cancancan, simple_form, solr, sinatra, тысячи их.
Поиск гемов https://www.ruby-toolbox.com
12. Зачем нужны тесты и как их писать?
http://rusrails.ru/a-guide-to-testing-rails-applications
http://habrahabr.ru/post/163597/
Вместо этого можно прочитать классную книгу Everyday Rails Testing
13. Где можно задать глупые и не очень вопросы?
- здесь
- stackoverflow.com
- тематические slack-конфы
- а вообще, гугли, с вероятностью в 90% ответ на твой вопрос уже висит на stackoverflow.
14. Как фокнуть\сделать фичу\исправить баг, сложно ли это?
Нет, не сложно. На rubyflow появляется много новостей с реализацией новой библиотеки, вы можете сделать тесты, фичу для него, старые либы также обрастают багами, улучшайте их! пишите код.
15. В чём писать код?
Atom, Brackets, Sublime Text, TextMate, Vim, GNU Emacs. Для особо упоротых энтерпрайз-макак есть rubymine, плагины к эклипс и нетбинс.
16. Можно ли писать на руби с под windows?
Можно, но придется обрасти костылями в виде виртуальной машины, придется сходу разбираться с Vagrant и многим другим. Чем дальше ты продвигаешься, тем ближе становится ясно, что пора перекатываться на linux/mac
17. Руби язык одного фреймворка?
Есть еще Sinatra, Hanami (ранее Lotus), Volt, Grape, отличные штуки для DevOps - Chef, Puppet и годные генераторы для бложиков - Jekyll, Middleman, всё это активно используется в продакшене
18. Можно ли делать игры на Ruby?
Можно, но не нужно. Гем Gosu.
19. Ютуб каналы
Youtube driven development...
Вот тебе пара каналов, но никому не говори что учишься по видео.
https://www.youtube.com/channel/UCIQmhQxCvLHRr3Beku77tww/videos
https://www.youtube.com/channel/UCfWZwsP8trUy5uHJg8gcGIQ
https://www.youtube.com/channel/UCSI77lJlzlCFPLdV1RSAoYQ
https://www.youtube.com/channel/UCPIyDzf1vwWc8EQJGUX-vYw - тут на ру$$ком даже.
20. Как и где искать работу?
Легко и просто - http://rubyjobs.ru/
Не так просто - https://upwork.com/
Еще вконтакте есть группы по руби/рельсам, там иногда постят вакансии. Еще в русской гугл группе постят вакансии. Новичку будет сложно, но возможно.
TODO лист для ньюфагов:
И так, ты поставил руби, уже сгенерировал свой первый проект rails new pidaras
Начни уже с платинового пути, блог >> клон твиттера >> своя имейджборда >> свой гем >> дальше сам придумаешь.
Рекомендации:
1. Для блога, создать роли, Админ, Пользователь (можно использовать паттерн form object). Прикрутить лайки, комментарии.
2. По твиттеру, следуя гайду Хартла, пиши все то что он предлагает в качестве доп. заданий, например оповещение по нику (@eblan: привет)
3. По имиджборде: воссоздать по возможности полный функционал, в этом случае придется ознакомится с javascript/jquery/coffeescript, но тебе так или иначе придется. Еще хорошей фичей будет использование background job и крон тасков (sidekiq, whenever), чтобы заполнять свою борду тредами и постами с другой борды, можно использовать api двача, чтобы вытягивать треды и посты - https://github.com/ID25/api_2ch
4. Не стесняемся постить свои репозитории, наши эксперты с радостью отревьювят вас.
После этого тебе будут нужны паттерны, без них твой код превратится в говно. Один из часто используемых - Service Object.
https://netguru.co/blog/service-objects-in-rails-will-help - о сервисах
Еще паттернов - https://robots.thoughtbot.com/back-to-basics-solid
Но самый читаемый код, как и следовало ожидать, даёт функциональное программирование. Начни отсюда:
http://www.sitepoint.com/functional-programming-techniques-with-ruby-part-i/
http://www.sitepoint.com/functional-programming-techniques-with-ruby-part-ii/
http://www.sitepoint.com/functional-programming-techniques-with-ruby-part-iii/
http://www.sitepoint.com/functional-programming-pure-functions/
http://www.sitepoint.com/functional-programming-ruby-value-objects/
Только не переборщи. Руби - не функциональный язык, и иногда такой код может работать медленней.
Прочитал? Теперь рефактори то, что уже написал. И не забывай покрывать тестами.
Хорошим финалом будет деплой, это пожалуй самое болезненное, и ничего общего с деплоем на heroku, где тыц тыц и готово. Придется поковыряться со смежными вещами и узнать много нового, уже устоявшийся гем для таких дел - Capistrano.
Не забывайте спрашивать у анонасов вопросы, код лучше показывать через gist или pastebin с подсветочкой.
Ну, а мы открываем очередной Ruby Thread.
>>26362
На самом деле ты прав. Хотел вспомнить свои влажные мечты далекого 15 года.
Сейчас увы из-за рынка пришлось перекатится на голанг. Да и платят чуток выше.
На самом деле ты прав. Хотел вспомнить свои влажные мечты далекого 15 года.
Сейчас увы из-за рынка пришлось перекатится на голанг. Да и платят чуток выше.
>>26359
Твой гайд великоват. Лучше бы чаще сидел тут.
Твой гайд великоват. Лучше бы чаще сидел тут.
>>26368
Рассказывай как перекатывался, интересно же
Рассказывай как перекатывался, интересно же
>>24696
dry-rb
https://www.icelab.com.au/notes/effective-ruby-dependency-injection-at-scale/
>А если не стабать, то как тогда? Dependency Injection? Но в таком случае наш объект помимо своих основных параметров должен принимать еще штук пять DI-инъекций. Код превратится во что-то неперевариваемое.
dry-rb
https://www.icelab.com.au/notes/effective-ruby-dependency-injection-at-scale/
>>26636
Пробовал использовать. Какое-то оверинжиниред говно по ощущением. Только валидации и транзакции более-менее понравились.
>dry-rb
Пробовал использовать. Какое-то оверинжиниред говно по ощущением. Только валидации и транзакции более-менее понравились.
>>26644
Оно говно, если не писать в стиле автора гемов, но тебе не нужно юзать весь стек, возьми только то, что добавили там для DI
Оно говно, если не писать в стиле автора гемов, но тебе не нужно юзать весь стек, возьми только то, что добавили там для DI
>>24696
Если тебе сложно написать тест для юнита(класс, контроллер, модель, неважно), то значит этот модуль делает слишком дохуя вещей. И лучшее решение в этом случае - это НЕ продолжать писать сложные тесты и думать, какими фабриками-хуябриками их можно сделать читабельнее, а упростить сам юнит. То есть вынести из него часть логики, протестировать эту логику отдельно, а в тесте для юнита проверять только то, что эта логика используется в принципе.
Ну зависят, ииии что? Тестировать надо не объект, а юзкейс. Если твой юзкейс - это создать пользователя в базе, то тесты будут выглядеть вот так:
1) GIVEN такие-то параметры
1) WHEN я вызываю кусок публичного API(например публичный метод класса, POST /users, обычная функция, и т.д)
2) THEN В базе создается юзер с такими параметрами и API возвращает мне юзера в таком формате
Это все. Тест пишется ТОЛЬКО с позиции пользователя API, будь то юзер на сайте или программист. И соответственно в тесте должна быть только та информация, которая доступна пользователю API. Там не должно быть хуйни вроде "если у меня замокан вот этот класс, замокана БД и вот эта переменная выставлена на 0, то метод в классе вернет :sosi_hui". Потому что это не то, как пользуются твоим API.
Пример вещей, достойных моканья:
1) То, над чем ты не имеешь контроля в принципе, как API стороннего сервиса, например web API ютуба
2) Кусок легаси кода, который ты переписываешь, но не планируешь менять вообще
Пример вещей, недостойных моканья:
1) БД
2) Любой собственный код в проекте
3) Любой сторонний код в проекте(либы)
Заодно можешь посмотреть отличное выступление, где все эти вещи объясняются более подробно:
https://www.youtube.com/watch?v=EZ05e7EMOLM
>Но есть задачи со сложной предметной областью: когда у моделей/проекта есть жизненный цикл с множеством состояний и ветвистый процесс.
Если тебе сложно написать тест для юнита(класс, контроллер, модель, неважно), то значит этот модуль делает слишком дохуя вещей. И лучшее решение в этом случае - это НЕ продолжать писать сложные тесты и думать, какими фабриками-хуябриками их можно сделать читабельнее, а упростить сам юнит. То есть вынести из него часть логики, протестировать эту логику отдельно, а в тесте для юнита проверять только то, что эта логика используется в принципе.
>Вот в Рспеке есть стабы и запись типа allow_any_instance_of to_recieve... И оговорка, что вообще-то это прием для легаси кода, и этого надо избегать.
>А как же избегать, если тестируемые процессы много от чего зависят.
Ну зависят, ииии что? Тестировать надо не объект, а юзкейс. Если твой юзкейс - это создать пользователя в базе, то тесты будут выглядеть вот так:
1) GIVEN такие-то параметры
1) WHEN я вызываю кусок публичного API(например публичный метод класса, POST /users, обычная функция, и т.д)
2) THEN В базе создается юзер с такими параметрами и API возвращает мне юзера в таком формате
Это все. Тест пишется ТОЛЬКО с позиции пользователя API, будь то юзер на сайте или программист. И соответственно в тесте должна быть только та информация, которая доступна пользователю API. Там не должно быть хуйни вроде "если у меня замокан вот этот класс, замокана БД и вот эта переменная выставлена на 0, то метод в классе вернет :sosi_hui". Потому что это не то, как пользуются твоим API.
Пример вещей, достойных моканья:
1) То, над чем ты не имеешь контроля в принципе, как API стороннего сервиса, например web API ютуба
2) Кусок легаси кода, который ты переписываешь, но не планируешь менять вообще
Пример вещей, недостойных моканья:
1) БД
2) Любой собственный код в проекте
3) Любой сторонний код в проекте(либы)
Заодно можешь посмотреть отличное выступление, где все эти вещи объясняются более подробно:
https://www.youtube.com/watch?v=EZ05e7EMOLM
>>24696
Если тебе сложно написать тест для юнита(класс, контроллер, модель, неважно), то значит этот модуль делает слишком дохуя вещей. И лучшее решение в этом случае - это НЕ продолжать писать сложные тесты и думать, какими фабриками-хуябриками их можно сделать читабельнее, а упростить сам юнит. То есть вынести из него часть логики, протестировать эту логику отдельно, а в тесте для юнита проверять только то, что эта логика используется в принципе.
Ну зависят, ииии что? Тестировать надо не объект, а юзкейс. Если твой юзкейс - это создать пользователя в базе, то тесты будут выглядеть вот так:
1) GIVEN такие-то параметры
1) WHEN я вызываю кусок публичного API(например публичный метод класса, POST /users, обычная функция, и т.д)
2) THEN В базе создается юзер с такими параметрами и API возвращает мне юзера в таком формате
Это все. Тест пишется ТОЛЬКО с позиции пользователя API, будь то юзер на сайте или программист. И соответственно в тесте должна быть только та информация, которая доступна пользователю API. Там не должно быть хуйни вроде "если у меня замокан вот этот класс, замокана БД и вот эта переменная выставлена на 0, то метод в классе вернет :sosi_hui". Потому что это не то, как пользуются твоим API.
Пример вещей, достойных моканья:
1) То, над чем ты не имеешь контроля в принципе, как API стороннего сервиса, например web API ютуба
2) Кусок легаси кода, который ты переписываешь, но не планируешь менять вообще
Пример вещей, недостойных моканья:
1) БД
2) Любой собственный код в проекте
3) Любой сторонний код в проекте(либы)
Заодно можешь посмотреть отличное выступление, где все эти вещи объясняются более подробно:
https://www.youtube.com/watch?v=EZ05e7EMOLM
>Но есть задачи со сложной предметной областью: когда у моделей/проекта есть жизненный цикл с множеством состояний и ветвистый процесс.
Если тебе сложно написать тест для юнита(класс, контроллер, модель, неважно), то значит этот модуль делает слишком дохуя вещей. И лучшее решение в этом случае - это НЕ продолжать писать сложные тесты и думать, какими фабриками-хуябриками их можно сделать читабельнее, а упростить сам юнит. То есть вынести из него часть логики, протестировать эту логику отдельно, а в тесте для юнита проверять только то, что эта логика используется в принципе.
>Вот в Рспеке есть стабы и запись типа allow_any_instance_of to_recieve... И оговорка, что вообще-то это прием для легаси кода, и этого надо избегать.
>А как же избегать, если тестируемые процессы много от чего зависят.
Ну зависят, ииии что? Тестировать надо не объект, а юзкейс. Если твой юзкейс - это создать пользователя в базе, то тесты будут выглядеть вот так:
1) GIVEN такие-то параметры
1) WHEN я вызываю кусок публичного API(например публичный метод класса, POST /users, обычная функция, и т.д)
2) THEN В базе создается юзер с такими параметрами и API возвращает мне юзера в таком формате
Это все. Тест пишется ТОЛЬКО с позиции пользователя API, будь то юзер на сайте или программист. И соответственно в тесте должна быть только та информация, которая доступна пользователю API. Там не должно быть хуйни вроде "если у меня замокан вот этот класс, замокана БД и вот эта переменная выставлена на 0, то метод в классе вернет :sosi_hui". Потому что это не то, как пользуются твоим API.
Пример вещей, достойных моканья:
1) То, над чем ты не имеешь контроля в принципе, как API стороннего сервиса, например web API ютуба
2) Кусок легаси кода, который ты переписываешь, но не планируешь менять вообще
Пример вещей, недостойных моканья:
1) БД
2) Любой собственный код в проекте
3) Любой сторонний код в проекте(либы)
Заодно можешь посмотреть отличное выступление, где все эти вещи объясняются более подробно:
https://www.youtube.com/watch?v=EZ05e7EMOLM
>>26636
>>26644
Блять, пиздец просто. Не дай бог после таких проект поддерживать.
Когда кто-то предлагает драй на полном серьезе, это повод задуматься не то что о профпригодности, а о вменяемости человека.
>>26688
Сори, но ты какой-то теоретик в вакууме с предрасположенностью к наставничеству.
Написано же было в посте "когда есть сложный контекст".
Ну усложни свой пример с созданием пользователя тем, что в случае, если на данный момент недоступен сервис проверки паспорта, то API должно вернуть failure с соответствующим сообщением/кодом.
Добавь условие, что если сейчас закрыта регистрация, то опять же соответствующая ошибка.
Добавь условие, что "регистрация закрыта" вычисляемое условие. Например конкурс завершен или на конкурсе уже достаточно заявок или на конкурсе уже выбраны команды или на текущем конкурсе только в обеденный перерыв можно регаться.
Добавь условие про количество невалидных попыток.
И тд и тп. Это еще примитивный случай, тут нет жизненного цикла.
Что нам поможет? Либо охуевший DI либо стабы.
Либо, если не все идеально распихано по модулям и функциям и нечего застабать, то придется моделировать состояние системы. Его иногда и так придется моделировать.
Офтопом:
Я, конечно, понимаю, что это была дежурная цитата. Все так, безусловно. Но наверняка найдется будущий художник фрактальных котов. Для таких хочется напомнить про
>>26644
Блять, пиздец просто. Не дай бог после таких проект поддерживать.
Когда кто-то предлагает драй на полном серьезе, это повод задуматься не то что о профпригодности, а о вменяемости человека.
>>26688
Сори, но ты какой-то теоретик в вакууме с предрасположенностью к наставничеству.
Написано же было в посте "когда есть сложный контекст".
Ну усложни свой пример с созданием пользователя тем, что в случае, если на данный момент недоступен сервис проверки паспорта, то API должно вернуть failure с соответствующим сообщением/кодом.
Добавь условие, что если сейчас закрыта регистрация, то опять же соответствующая ошибка.
Добавь условие, что "регистрация закрыта" вычисляемое условие. Например конкурс завершен или на конкурсе уже достаточно заявок или на конкурсе уже выбраны команды или на текущем конкурсе только в обеденный перерыв можно регаться.
Добавь условие про количество невалидных попыток.
И тд и тп. Это еще примитивный случай, тут нет жизненного цикла.
Что нам поможет? Либо охуевший DI либо стабы.
Либо, если не все идеально распихано по модулям и функциям и нечего застабать, то придется моделировать состояние системы. Его иногда и так придется моделировать.
Офтопом:
>Если тебе сложно написать тест для юнита(класс, контроллер, модель, неважно), то значит этот модуль делает слишком дохуя вещей.
Я, конечно, понимаю, что это была дежурная цитата. Все так, безусловно. Но наверняка найдется будущий художник фрактальных котов. Для таких хочется напомнить про
>Ravioli code is a term specific to object-oriented programming. It describes code that comprises well-structured classes that are easy to understand in isolation, but difficult to understand as a whole.
>>26922
PS: Извиняюсь за резкость на счет драя. Анон вероятно просто хотел указать на решения по инжекту. Но драй очень дерьмовое решение, использующим его нет оправдания.
PS: Извиняюсь за резкость на счет драя. Анон вероятно просто хотел указать на решения по инжекту. Но драй очень дерьмовое решение, использующим его нет оправдания.
>>26922
Я тебе наоборот дал самые практические советы из личного опыта TDD с минимумом теорий.
Эти проверки выносятся в отдельный модуль/класс, как только ты понимаешь, что через контролер их тестировать неудобно, и в итоге контролер вызывает, например метод check_registration_availability, внутри которого проверяется что угодно: открытая/закрытая регистрация, предыдущие попытки, доступность API. Контролер не ебет, что там проверяется, он просто знает, что если метод вернул availability.success? == true, то можно продолжить регистрацию, если false, то отрендерить availability.errors и завершить выполнение запроса. Внутри модуля проверок их точно так же можно вынести в свои отдельные модули, как только тестировать нюанс каждой проверки становится неудобно.
И соотвественно в тестах для контроллера тебе достаточно добавить один простой кейс, что доступность регистрации проверяется в принципе, и что пользователю возвращаются какие-то ошибки, если регистрация недоступна. Потому что это как раз ответственность контроллера. Без нюансов, т.к нюансы уже покрыты в тестах для другого модуля. Я в таких случаях обычно беру из модуля регистрации самый простой юзкейс, который почти наверняка не поменяется, и дублирую его в тесте для контроллера. Либо, если тебе очень не хочется дублировать, то можно вынести данный юзкейс тоже в отдельный модуль и использовать его в обоих тестах. Моки тут только навредят.
Если тебе нужно засетапить валидную check_registration_availability, например для последующих тестов внутри контроллера, то ты так же выносишь весь сетап в отдельный модуль(желательно этот модуль хранить рядом с тестами на проверку регистрации, а еще лучше, если тесты на проверку регистрацию этот модуль используют сами), в котором будет метод setup_available_registration, который ты будешь вызывать перед каждым тестом контроллера, где тебе он нужен.
Хз, как можно еще более подробно расписать, разве что только кодом.
Я тебе наоборот дал самые практические советы из личного опыта TDD с минимумом теорий.
>Ну усложни свой пример с созданием пользователя
Эти проверки выносятся в отдельный модуль/класс, как только ты понимаешь, что через контролер их тестировать неудобно, и в итоге контролер вызывает, например метод check_registration_availability, внутри которого проверяется что угодно: открытая/закрытая регистрация, предыдущие попытки, доступность API. Контролер не ебет, что там проверяется, он просто знает, что если метод вернул availability.success? == true, то можно продолжить регистрацию, если false, то отрендерить availability.errors и завершить выполнение запроса. Внутри модуля проверок их точно так же можно вынести в свои отдельные модули, как только тестировать нюанс каждой проверки становится неудобно.
И соотвественно в тестах для контроллера тебе достаточно добавить один простой кейс, что доступность регистрации проверяется в принципе, и что пользователю возвращаются какие-то ошибки, если регистрация недоступна. Потому что это как раз ответственность контроллера. Без нюансов, т.к нюансы уже покрыты в тестах для другого модуля. Я в таких случаях обычно беру из модуля регистрации самый простой юзкейс, который почти наверняка не поменяется, и дублирую его в тесте для контроллера. Либо, если тебе очень не хочется дублировать, то можно вынести данный юзкейс тоже в отдельный модуль и использовать его в обоих тестах. Моки тут только навредят.
Если тебе нужно засетапить валидную check_registration_availability, например для последующих тестов внутри контроллера, то ты так же выносишь весь сетап в отдельный модуль(желательно этот модуль хранить рядом с тестами на проверку регистрации, а еще лучше, если тесты на проверку регистрацию этот модуль используют сами), в котором будет метод setup_available_registration, который ты будешь вызывать перед каждым тестом контроллера, где тебе он нужен.
Хз, как можно еще более подробно расписать, разве что только кодом.
уже давно пытаюсь во что-нибудь вкатиться и вдруг Постиг понимания что кристал крайне многообещающий проект, и странным образом он практически полностью(?) идентичен по синтаксису с раби. Посмотрел примеры кода на rosettacode, и на кристале они ясны практически как божий день, в отличие от остального туманного говна, в которое надо изрядно вникать. даже в питоноподобную хуйню, она же нечитабельна по сравнению с кристало-раби, ну совсем не читабельна же Проект молодой, но, сука, донатов на него в bountysource $2,502 против $856 на Nim. Который мне, как ньюфагу, поначалу казался охуенно любопытным продуктом.
забыл блядь что хотел спросить
Так вот. Мне вообще похуй на веб и всё такое, у меня бекграунд вообще музыкальный, то есть частично хотелось бы заниматься DSP обработкой, и я знаю что там царит сплошной с++. Но я минималист.
И глядя на то как, сука, прост код фурье обработки на кристале, может быть и двигло на нём было бы не настолько сложно какое-то (на/до)писать, чтобы сделать, к примеру, 2D игрушку? (вопрос по сути риторический)
https://rosettacode.org/wiki/Fast_Fourier_transform#Crystal
Вроде и под андроид есть для раби какие-то обёртки.
не знаю нахуя я это написал, мне по сути нечего спросить, запосчу просто так
забыл блядь что хотел спросить
Так вот. Мне вообще похуй на веб и всё такое, у меня бекграунд вообще музыкальный, то есть частично хотелось бы заниматься DSP обработкой, и я знаю что там царит сплошной с++. Но я минималист.
И глядя на то как, сука, прост код фурье обработки на кристале, может быть и двигло на нём было бы не настолько сложно какое-то (на/до)писать, чтобы сделать, к примеру, 2D игрушку? (вопрос по сути риторический)
https://rosettacode.org/wiki/Fast_Fourier_transform#Crystal
Вроде и под андроид есть для раби какие-то обёртки.
не знаю нахуя я это написал, мне по сути нечего спросить, запосчу просто так
>>27382
Хочешь веб и руби - бери эликсир. Хочешь андроид - бери жабу. Хочешь сам не знаешь что - бери питон. "Читабельность" зависит только от уровня твоего знакомства с синтаксисом и от опыта программиста, который писал код, в любом языке.
Хочешь веб и руби - бери эликсир. Хочешь андроид - бери жабу. Хочешь сам не знаешь что - бери питон. "Читабельность" зависит только от уровня твоего знакомства с синтаксисом и от опыта программиста, который писал код, в любом языке.
>>27392
Нет. Код на каком-нибудь коболе может быть читабельным по-сравнению с другим кодом на коболе, но он никогда не станет таким же читабельным как аналогичный код на том же руби. Потому что в коболе на уровне синтаксиса языка нету возможности написать такой же читабельный код.
>"Читабельность" зависит только от уровня твоего знакомства с синтаксисом и от опыта программиста
Нет. Код на каком-нибудь коболе может быть читабельным по-сравнению с другим кодом на коболе, но он никогда не станет таким же читабельным как аналогичный код на том же руби. Потому что в коболе на уровне синтаксиса языка нету возможности написать такой же читабельный код.
>>27392
осилить все можно все-вопрос во времени и информации по теме
осилить все можно все-вопрос во времени и информации по теме
>>27399
Если у тебя дохуя опыта написания кода на коболе и дохуя написания кода на руби, то синтаксические конструкции ты будешь читать и понимать с одинаковой скоростью, что там, что там. Это и есть читабельность, она всегда личная и зависит от опыта. Дальше вопрос только в выразительности языка на строчку кода.
Если у тебя дохуя опыта написания кода на коболе и дохуя написания кода на руби, то синтаксические конструкции ты будешь читать и понимать с одинаковой скоростью, что там, что там. Это и есть читабельность, она всегда личная и зависит от опыта. Дальше вопрос только в выразительности языка на строчку кода.
>>27408
Точнее эликсир. И слава богу, что феникс не пошел по пути рельс, когда экосистема фреймворка подменяет собой экосистему языка.
Точнее эликсир. И слава богу, что феникс не пошел по пути рельс, когда экосистема фреймворка подменяет собой экосистему языка.
>>27411
ну согласись,на руби приятнее читать,код чист от нагромождений,более логичен для человеческого мозга
ну согласись,на руби приятнее читать,код чист от нагромождений,более логичен для человеческого мозга
>>27382
Не надо C++ нет нет нет нет не надо больше нам такого, теперь есть Julia, она умеет на видеокартах считать. И синтаксис на Ruby похож.
Не надо C++ нет нет нет нет не надо больше нам такого, теперь есть Julia, она умеет на видеокартах считать. И синтаксис на Ruby похож.
>>27418
Знаю про юлию, но как-то не зашла она у меня с позиции новичка. Возможно потом зайдёт после кристало-раби питоноподобный синтаксис (он же в юлии питоноподобен, а не раби-подобен, если я правильно понимаю) удобен для того чтобы на нём писать бухим в говно, но не для того чтобы его потом кто-то читал? Я же предполагаю что мне придётся всё таки читать чей-то код, его фиксить, а если он прям щас у меня почти что зашёл, без знания языка, так потом вообще нормально будет, кпд на единицу времени по итогам будет выше(?)
Знаю про юлию, но как-то не зашла она у меня с позиции новичка. Возможно потом зайдёт после кристало-раби питоноподобный синтаксис (он же в юлии питоноподобен, а не раби-подобен, если я правильно понимаю) удобен для того чтобы на нём писать бухим в говно, но не для того чтобы его потом кто-то читал? Я же предполагаю что мне придётся всё таки читать чей-то код, его фиксить, а если он прям щас у меня почти что зашёл, без знания языка, так потом вообще нормально будет, кпд на единицу времени по итогам будет выше(?)
>>27450
Писать читаемый код - это огромная наука, которую можно освоить только на практике, написав перед этим тонны нечитаемого говна. От языка это зависит очень мало, ты все равно будешь писать хуйню и потом хвататься за голову, когда эту хуйню нужно будет через неделю прочитать и вспомнить, что она делает. Хоть на руби, хоть на джаве. Так что не заебывайся, выбирай язык под задачу, а не по красивости синтаксиса, и иди практикуйся. Потом можешь еще почитать всякие code complete, clean code, чтобы подхватить и сопоставить со своим опытом уже сформулированные концепции по написанию читаемого кода, но полезны они будут только после/во время практики, а не перед ней.
Писать читаемый код - это огромная наука, которую можно освоить только на практике, написав перед этим тонны нечитаемого говна. От языка это зависит очень мало, ты все равно будешь писать хуйню и потом хвататься за голову, когда эту хуйню нужно будет через неделю прочитать и вспомнить, что она делает. Хоть на руби, хоть на джаве. Так что не заебывайся, выбирай язык под задачу, а не по красивости синтаксиса, и иди практикуйся. Потом можешь еще почитать всякие code complete, clean code, чтобы подхватить и сопоставить со своим опытом уже сформулированные концепции по написанию читаемого кода, но полезны они будут только после/во время практики, а не перед ней.
>>27418
julia не нужна, потому что есть numba
julia не нужна, потому что есть numba
>>26934
Так а я разве отрицаю? Но мы и приходим к стабам
allow_any_instance_of(SomePolicy).to receive(:check_registration_availability).and_return(true)
При том это мы говорим об идеальном допущении, что логика была грамотно осознана и структурирована, а внутри SomePolicy отрабатывает еще десяток (без преувеличения, именно для нашего примера) других SubPolicy и все их получилось (!) органично собрать в единый механизм, сведенный к единственному методу.
То есть должна быть очень сильная декомпозиция. Например, в коде тестируемого сервис-обджекта не может быть ничего подобного:
policy = @user.legal_status == 'phisical' ? PhisicalPolicy : JuridicalPolicy
А вместо этого будет обертка типа LegalPolicy:
policy = LegalPolicy.new(@user, ...)
В противном случае мы уже должны вводить контекст в виде пользователя с какой-то правовой формой.
Кстати, тоже хотел давно спросить, как распихивать такой набор по файловой системе? В рельсах нет модульности и если это делать по технической иерархии (policies, models, etc), то получается каша.
Другая ситуация - когда мы работаем с жизненным циклом и с какой-то структурой лень сейчас придумывать конкретный пример. Суть в том, что наш модуль должен ответить на один единственный вопрос. Но чтобы ответить он должен проанализировать состояние сложного контекста - функция от нескольких моделей с их сочетанием полей.
Или при тестировании query-обджектов, иногда под запрос нужно создать сложный набор.
>Эти проверки выносятся в отдельный модуль/класс
>соотвественно в тестах для контроллера тебе достаточно добавить один простой кейс, что доступность регистрации проверяется в принципе
Так а я разве отрицаю? Но мы и приходим к стабам
allow_any_instance_of(SomePolicy).to receive(:check_registration_availability).and_return(true)
При том это мы говорим об идеальном допущении, что логика была грамотно осознана и структурирована, а внутри SomePolicy отрабатывает еще десяток (без преувеличения, именно для нашего примера) других SubPolicy и все их получилось (!) органично собрать в единый механизм, сведенный к единственному методу.
То есть должна быть очень сильная декомпозиция. Например, в коде тестируемого сервис-обджекта не может быть ничего подобного:
policy = @user.legal_status == 'phisical' ? PhisicalPolicy : JuridicalPolicy
А вместо этого будет обертка типа LegalPolicy:
policy = LegalPolicy.new(@user, ...)
В противном случае мы уже должны вводить контекст в виде пользователя с какой-то правовой формой.
Кстати, тоже хотел давно спросить, как распихивать такой набор по файловой системе? В рельсах нет модульности и если это делать по технической иерархии (policies, models, etc), то получается каша.
Другая ситуация - когда мы работаем с жизненным циклом и с какой-то структурой лень сейчас придумывать конкретный пример. Суть в том, что наш модуль должен ответить на один единственный вопрос. Но чтобы ответить он должен проанализировать состояние сложного контекста - функция от нескольких моделей с их сочетанием полей.
Или при тестировании query-обджектов, иногда под запрос нужно создать сложный набор.
>>27524
Не приходим. То есть ты конечно можешь их использовать, но сразу охуеешь, если захочешь поменять структуру кода, не меняя при этом его поведение(рефакторинг). Тесты должны этому помогать, а со стабами/моками ты ломаешь инкапсуляцию, потому что теперь твой тест знает гораздо больше, чем должен(что внутри тестируемого компонента есть конкретная SomePolicy с конкретным методом, который ожидает конкретные параметры), и при этом прочно связываешь тест с конкретной внутренней реализацией тестируемого компонента. Из-за чего менять внутреннюю реализацию компонента будет невозможно, не поменяв тест.
Марка качества для теста - это именно рефакторинг. Если ты можешь как угодно зарефакторить комопнент, при этом не тронув ни одной строчки в тесте, и тест при этом останется зеленым, то это хороший тест. В твоем примере придется трогать как минимум один стаб, а скорее всего и еще что-то. Это контрпродуктивно и очень неудобно.
В том и дело, что тестам должно быть абсолютно похуй на то, как твоя логика структурирована внутри. Они проверяют конкретные юзкейсы, а не конкретные куски логики внутри приложения. Между этими двумя вещами есть разница. Если, допустим, логика проверки регистрации не засунута в отдельный класс, а написана прямо внутри контролера, то тебе просто-напросто придется писать больше тестов для контролера, которые тестируют эту логику. Как только ты вынесешь логику проверок в отдельный компонент - ты сможешь во-первых протестировать ее отдельно, не дергая контролер, а во вторых удалить из тестов для контролера все повторяющиеся(и до сих пор зеленые) кейсы этой логики, оставив только один.
Распихивать надо так, чтобы вещи, которые меняются вместе, были рядом. В этом плане рельсы и многие другие популярные фреймворки делают полную хуйню. Вместо
/models/user.rb
/models/role.rb
/controllers/users_controller.rb
/controllers/roles_controller.rb
Должно быть
/user/model.rb
/user/controller.rb
/role/model.rb
/role/controller.rb
И т.д. Просто потому, что в твоем проекте никогда не встанет задача "поменять какую-то хуйню во всех моделях/контроллерах"(а даже если и встанет, ты не будешь менять это в каждой модели, а пойдешь в ActiveRecord::Base), но зато задачи "поменять хуйню в юзерах, которая затронет контролер юзера, модель юзера, сервис юзера и прочее у юзера" возникают постоянно. Со второй схемой ты просто идешь в папку user и меняешь там нужную логику в нужных файлах, а с первой - прыгаешь туда-сюда. Я уверен, что такое относительно просто организовать даже в рельсах с их магией, но сам уже давно рельсы забросил и постепенно переношу свой последний крупный проект на эликсир. Вообще советую тебе попробовать отдохнуть от рельс и написать что-то либо на другом языке, либо на чистом руби. Рельсы слишком извращают мышление и закрывают собой кучу хороших простых практик, поощряя вместо них лютый оверинжинирнг. А в последних версиях там вроде вообще пиздец нагородили.
>Но мы и приходим к стабам
Не приходим. То есть ты конечно можешь их использовать, но сразу охуеешь, если захочешь поменять структуру кода, не меняя при этом его поведение(рефакторинг). Тесты должны этому помогать, а со стабами/моками ты ломаешь инкапсуляцию, потому что теперь твой тест знает гораздо больше, чем должен(что внутри тестируемого компонента есть конкретная SomePolicy с конкретным методом, который ожидает конкретные параметры), и при этом прочно связываешь тест с конкретной внутренней реализацией тестируемого компонента. Из-за чего менять внутреннюю реализацию компонента будет невозможно, не поменяв тест.
Марка качества для теста - это именно рефакторинг. Если ты можешь как угодно зарефакторить комопнент, при этом не тронув ни одной строчки в тесте, и тест при этом останется зеленым, то это хороший тест. В твоем примере придется трогать как минимум один стаб, а скорее всего и еще что-то. Это контрпродуктивно и очень неудобно.
>При том это мы говорим об идеальном допущении, что логика была грамотно осознана и структурирована
>То есть должна быть очень сильная декомпозиция.
В том и дело, что тестам должно быть абсолютно похуй на то, как твоя логика структурирована внутри. Они проверяют конкретные юзкейсы, а не конкретные куски логики внутри приложения. Между этими двумя вещами есть разница. Если, допустим, логика проверки регистрации не засунута в отдельный класс, а написана прямо внутри контролера, то тебе просто-напросто придется писать больше тестов для контролера, которые тестируют эту логику. Как только ты вынесешь логику проверок в отдельный компонент - ты сможешь во-первых протестировать ее отдельно, не дергая контролер, а во вторых удалить из тестов для контролера все повторяющиеся(и до сих пор зеленые) кейсы этой логики, оставив только один.
>Кстати, тоже хотел давно спросить, как распихивать такой набор по файловой системе?
Распихивать надо так, чтобы вещи, которые меняются вместе, были рядом. В этом плане рельсы и многие другие популярные фреймворки делают полную хуйню. Вместо
/models/user.rb
/models/role.rb
/controllers/users_controller.rb
/controllers/roles_controller.rb
Должно быть
/user/model.rb
/user/controller.rb
/role/model.rb
/role/controller.rb
И т.д. Просто потому, что в твоем проекте никогда не встанет задача "поменять какую-то хуйню во всех моделях/контроллерах"(а даже если и встанет, ты не будешь менять это в каждой модели, а пойдешь в ActiveRecord::Base), но зато задачи "поменять хуйню в юзерах, которая затронет контролер юзера, модель юзера, сервис юзера и прочее у юзера" возникают постоянно. Со второй схемой ты просто идешь в папку user и меняешь там нужную логику в нужных файлах, а с первой - прыгаешь туда-сюда. Я уверен, что такое относительно просто организовать даже в рельсах с их магией, но сам уже давно рельсы забросил и постепенно переношу свой последний крупный проект на эликсир. Вообще советую тебе попробовать отдохнуть от рельс и написать что-то либо на другом языке, либо на чистом руби. Рельсы слишком извращают мышление и закрывают собой кучу хороших простых практик, поощряя вместо них лютый оверинжинирнг. А в последних версиях там вроде вообще пиздец нагородили.
>>27524
Не приходим. То есть ты конечно можешь их использовать, но сразу охуеешь, если захочешь поменять структуру кода, не меняя при этом его поведение(рефакторинг). Тесты должны этому помогать, а со стабами/моками ты ломаешь инкапсуляцию, потому что теперь твой тест знает гораздо больше, чем должен(что внутри тестируемого компонента есть конкретная SomePolicy с конкретным методом, который ожидает конкретные параметры), и при этом прочно связываешь тест с конкретной внутренней реализацией тестируемого компонента. Из-за чего менять внутреннюю реализацию компонента будет невозможно, не поменяв тест.
Марка качества для теста - это именно рефакторинг. Если ты можешь как угодно зарефакторить комопнент, при этом не тронув ни одной строчки в тесте, и тест при этом останется зеленым, то это хороший тест. В твоем примере придется трогать как минимум один стаб, а скорее всего и еще что-то. Это контрпродуктивно и очень неудобно.
В том и дело, что тестам должно быть абсолютно похуй на то, как твоя логика структурирована внутри. Они проверяют конкретные юзкейсы, а не конкретные куски логики внутри приложения. Между этими двумя вещами есть разница. Если, допустим, логика проверки регистрации не засунута в отдельный класс, а написана прямо внутри контролера, то тебе просто-напросто придется писать больше тестов для контролера, которые тестируют эту логику. Как только ты вынесешь логику проверок в отдельный компонент - ты сможешь во-первых протестировать ее отдельно, не дергая контролер, а во вторых удалить из тестов для контролера все повторяющиеся(и до сих пор зеленые) кейсы этой логики, оставив только один.
Распихивать надо так, чтобы вещи, которые меняются вместе, были рядом. В этом плане рельсы и многие другие популярные фреймворки делают полную хуйню. Вместо
/models/user.rb
/models/role.rb
/controllers/users_controller.rb
/controllers/roles_controller.rb
Должно быть
/user/model.rb
/user/controller.rb
/role/model.rb
/role/controller.rb
И т.д. Просто потому, что в твоем проекте никогда не встанет задача "поменять какую-то хуйню во всех моделях/контроллерах"(а даже если и встанет, ты не будешь менять это в каждой модели, а пойдешь в ActiveRecord::Base), но зато задачи "поменять хуйню в юзерах, которая затронет контролер юзера, модель юзера, сервис юзера и прочее у юзера" возникают постоянно. Со второй схемой ты просто идешь в папку user и меняешь там нужную логику в нужных файлах, а с первой - прыгаешь туда-сюда. Я уверен, что такое относительно просто организовать даже в рельсах с их магией, но сам уже давно рельсы забросил и постепенно переношу свой последний крупный проект на эликсир. Вообще советую тебе попробовать отдохнуть от рельс и написать что-то либо на другом языке, либо на чистом руби. Рельсы слишком извращают мышление и закрывают собой кучу хороших простых практик, поощряя вместо них лютый оверинжинирнг. А в последних версиях там вроде вообще пиздец нагородили.
>Но мы и приходим к стабам
Не приходим. То есть ты конечно можешь их использовать, но сразу охуеешь, если захочешь поменять структуру кода, не меняя при этом его поведение(рефакторинг). Тесты должны этому помогать, а со стабами/моками ты ломаешь инкапсуляцию, потому что теперь твой тест знает гораздо больше, чем должен(что внутри тестируемого компонента есть конкретная SomePolicy с конкретным методом, который ожидает конкретные параметры), и при этом прочно связываешь тест с конкретной внутренней реализацией тестируемого компонента. Из-за чего менять внутреннюю реализацию компонента будет невозможно, не поменяв тест.
Марка качества для теста - это именно рефакторинг. Если ты можешь как угодно зарефакторить комопнент, при этом не тронув ни одной строчки в тесте, и тест при этом останется зеленым, то это хороший тест. В твоем примере придется трогать как минимум один стаб, а скорее всего и еще что-то. Это контрпродуктивно и очень неудобно.
>При том это мы говорим об идеальном допущении, что логика была грамотно осознана и структурирована
>То есть должна быть очень сильная декомпозиция.
В том и дело, что тестам должно быть абсолютно похуй на то, как твоя логика структурирована внутри. Они проверяют конкретные юзкейсы, а не конкретные куски логики внутри приложения. Между этими двумя вещами есть разница. Если, допустим, логика проверки регистрации не засунута в отдельный класс, а написана прямо внутри контролера, то тебе просто-напросто придется писать больше тестов для контролера, которые тестируют эту логику. Как только ты вынесешь логику проверок в отдельный компонент - ты сможешь во-первых протестировать ее отдельно, не дергая контролер, а во вторых удалить из тестов для контролера все повторяющиеся(и до сих пор зеленые) кейсы этой логики, оставив только один.
>Кстати, тоже хотел давно спросить, как распихивать такой набор по файловой системе?
Распихивать надо так, чтобы вещи, которые меняются вместе, были рядом. В этом плане рельсы и многие другие популярные фреймворки делают полную хуйню. Вместо
/models/user.rb
/models/role.rb
/controllers/users_controller.rb
/controllers/roles_controller.rb
Должно быть
/user/model.rb
/user/controller.rb
/role/model.rb
/role/controller.rb
И т.д. Просто потому, что в твоем проекте никогда не встанет задача "поменять какую-то хуйню во всех моделях/контроллерах"(а даже если и встанет, ты не будешь менять это в каждой модели, а пойдешь в ActiveRecord::Base), но зато задачи "поменять хуйню в юзерах, которая затронет контролер юзера, модель юзера, сервис юзера и прочее у юзера" возникают постоянно. Со второй схемой ты просто идешь в папку user и меняешь там нужную логику в нужных файлах, а с первой - прыгаешь туда-сюда. Я уверен, что такое относительно просто организовать даже в рельсах с их магией, но сам уже давно рельсы забросил и постепенно переношу свой последний крупный проект на эликсир. Вообще советую тебе попробовать отдохнуть от рельс и написать что-то либо на другом языке, либо на чистом руби. Рельсы слишком извращают мышление и закрывают собой кучу хороших простых практик, поощряя вместо них лютый оверинжинирнг. А в последних версиях там вроде вообще пиздец нагородили.
>>27568
Слабая связность - не сильвер буллет, ебал я в рот продираться через миллионы тонких классов. Это тоже, знаешь ли, тоже очень неудобно.
При разумном использовании стабов поправить один интерфейс в тесте - не так страшно, как ты описываешь. То, что последователи solid будут недовольны - ну а как они с рельсой вообще живут? Стабов не нужно избегать, но пользоваться в ограниченном объёме. Сomplexity класса не может быть слишким низким или высоким, вот и весь секрет.
мимо
> В твоем примере придется трогать как минимум один стаб, а скорее всего и еще что-то. Это контрпродуктивно и очень неудобно.
Слабая связность - не сильвер буллет, ебал я в рот продираться через миллионы тонких классов. Это тоже, знаешь ли, тоже очень неудобно.
При разумном использовании стабов поправить один интерфейс в тесте - не так страшно, как ты описываешь. То, что последователи solid будут недовольны - ну а как они с рельсой вообще живут? Стабов не нужно избегать, но пользоваться в ограниченном объёме. Сomplexity класса не может быть слишким низким или высоким, вот и весь секрет.
мимо
>>27568
Вот теперь я тебя не понимаю. А как тогда тестировать кейс, когда логика внутри тестируемого юнита зависит от результата другого юнита? Ну то есть как тогда проверить, два сценария: 1) Policy вернула true 2) Policy вернула false, не создавая при этом соответствующих условий для нее?
Да, но если внутри есть суб-директории без скоуп-модулей, то автолоадинг перестает работать. Я сейчас сам прелоадю, но это как-то не очень красиво. инбифо, трейлблейзер идет нахуй
>>27906
Хорошо сказал про классы. Двачую. Только я не понял, почему "связность". SRP имелось в виду?
>Не приходим
>ты ломаешь инкапсуляцию, потому что теперь твой тест знает гораздо больше, чем должен(что внутри тестируемого компонента есть конкретная SomePolicy с конкретным методом, который ожидает конкретные параметры)
Вот теперь я тебя не понимаю. А как тогда тестировать кейс, когда логика внутри тестируемого юнита зависит от результата другого юнита? Ну то есть как тогда проверить, два сценария: 1) Policy вернула true 2) Policy вернула false, не создавая при этом соответствующих условий для нее?
>Распихивать надо так
Да, но если внутри есть суб-директории без скоуп-модулей, то автолоадинг перестает работать. Я сейчас сам прелоадю, но это как-то не очень красиво. инбифо, трейлблейзер идет нахуй
>>27906
Хорошо сказал про классы. Двачую. Только я не понял, почему "связность". SRP имелось в виду?
>>27906
Поэтому ты и пишешь вещи сверху-вниз, вынося в отдельные классы/паттерны/модули только тогда, когда это реально оправдано, улучшает читаемость или помогает внедрить изменение. И тесты в этом отлично помогают, если они конечно не замоканы.
Тут еще есть проблема в понимании определения стабов. Стаб - это затычка. Например, у тебя есть функция, которая требует 3 аргумента, но ты знаешь, что последний аргумент в данном тесте использоваться не будет вообще. И ты даешь этой функции стаб. Чем он проще - тем лучше. У стаба не должно быть никакой логики, он должен соотвествовать абсолютному минимум требований. allow receive - это не стаб, а полноценный мок с поведением. Стабы - это нормально, но они все равно используются довольно редко(и если тебе реально нужен стаб, то ты можешь его написать сам за минуту, без всяких мокинг либ). Моки - это не норма, а исключение, и должны использоваться еще реже, чем стабы.
>>28287
Сценарии должны звучать не как "компонент вернул true/false", а соотвествовать юзкейсам. Например, в контроллере у тебя были такие юзкейсы(и, соответственно, тесты для них)
a) Если регистрация закрыта, то API вернет ошибку 1
b) Если не проверить паспорт, то API вернет ошибку 2
c) Если не проверить еще что-то, то API вернет ошибку 3
d) Если регистрация открыта, паспорт и все остальное проверны, то API вернет что-то другое
... и т.д
Ты решил упростить контроллер и вынести пункты a-d в свою Policy. Для этого ты:
1) написал Policy
2) написал для нее тесты(по сути просто скопировал нужные тесткейсы из контроллера и подправил API).
3) Интегрировал Policy в контролер и убрал из контролера весь повторяющийся код
4) Прогнал все тесты для контролера, они должны быть зелеными.
5) Начинаешь убирать все повторяющиеся тесты внутри контроллера(эти тесты ты вынес в Policy на шаге 2). И вот тут важный момент - в контроллере нужно оставить тот минимум тестов, которые позволят тебе с уверенностью знать, что Policy контроллером на самом деле используется. Например, в контроллере остались тесты юзкейса а), юзкейса d) и нужный сетап для этих тестов.
6) Так как сетап повторяется и внутри тестов контроллера, и внутри тестов Policy, его логично и удобно вынести в общий модуль, который будет этими тестами использоваться
7) Опционально можно вынести оба повторяющихся теста в такой же модуль. Но можно и не выносить, если тесты очень простые и проверяют те юзкейсы, которые почти наверняка никогда не будут меняться.
Подобный процесс требует не сильно больше усилий, чем моканье, но при этом не привязывает твой код к текущей внутрней имплементации, и такие тесты будут ломаться только тогда, когда сломался реальный юзкейс, а не левый мок.
Это уже рельсопроблемы, тут ничего посоветовать не могу.
>Слабая связность - не сильвер буллет, ебал я в рот продираться через миллионы тонких классов.
Поэтому ты и пишешь вещи сверху-вниз, вынося в отдельные классы/паттерны/модули только тогда, когда это реально оправдано, улучшает читаемость или помогает внедрить изменение. И тесты в этом отлично помогают, если они конечно не замоканы.
>Стабов не нужно избегать, но пользоваться в ограниченном объёме.
Тут еще есть проблема в понимании определения стабов. Стаб - это затычка. Например, у тебя есть функция, которая требует 3 аргумента, но ты знаешь, что последний аргумент в данном тесте использоваться не будет вообще. И ты даешь этой функции стаб. Чем он проще - тем лучше. У стаба не должно быть никакой логики, он должен соотвествовать абсолютному минимум требований. allow receive - это не стаб, а полноценный мок с поведением. Стабы - это нормально, но они все равно используются довольно редко(и если тебе реально нужен стаб, то ты можешь его написать сам за минуту, без всяких мокинг либ). Моки - это не норма, а исключение, и должны использоваться еще реже, чем стабы.
>>28287
> А как тогда тестировать кейс, когда логика внутри тестируемого юнита зависит от результата другого юнита? Ну то есть как тогда проверить, два сценария: 1) Policy вернула true 2) Policy вернула false
Сценарии должны звучать не как "компонент вернул true/false", а соотвествовать юзкейсам. Например, в контроллере у тебя были такие юзкейсы(и, соответственно, тесты для них)
a) Если регистрация закрыта, то API вернет ошибку 1
b) Если не проверить паспорт, то API вернет ошибку 2
c) Если не проверить еще что-то, то API вернет ошибку 3
d) Если регистрация открыта, паспорт и все остальное проверны, то API вернет что-то другое
... и т.д
Ты решил упростить контроллер и вынести пункты a-d в свою Policy. Для этого ты:
1) написал Policy
2) написал для нее тесты(по сути просто скопировал нужные тесткейсы из контроллера и подправил API).
3) Интегрировал Policy в контролер и убрал из контролера весь повторяющийся код
4) Прогнал все тесты для контролера, они должны быть зелеными.
5) Начинаешь убирать все повторяющиеся тесты внутри контроллера(эти тесты ты вынес в Policy на шаге 2). И вот тут важный момент - в контроллере нужно оставить тот минимум тестов, которые позволят тебе с уверенностью знать, что Policy контроллером на самом деле используется. Например, в контроллере остались тесты юзкейса а), юзкейса d) и нужный сетап для этих тестов.
6) Так как сетап повторяется и внутри тестов контроллера, и внутри тестов Policy, его логично и удобно вынести в общий модуль, который будет этими тестами использоваться
7) Опционально можно вынести оба повторяющихся теста в такой же модуль. Но можно и не выносить, если тесты очень простые и проверяют те юзкейсы, которые почти наверняка никогда не будут меняться.
Подобный процесс требует не сильно больше усилий, чем моканье, но при этом не привязывает твой код к текущей внутрней имплементации, и такие тесты будут ломаться только тогда, когда сломался реальный юзкейс, а не левый мок.
>Да, но если внутри есть суб-директории без скоуп-модулей, то автолоадинг перестает работать
Это уже рельсопроблемы, тут ничего посоветовать не могу.
>>27906
Поэтому ты и пишешь вещи сверху-вниз, вынося в отдельные классы/паттерны/модули только тогда, когда это реально оправдано, улучшает читаемость или помогает внедрить изменение. И тесты в этом отлично помогают, если они конечно не замоканы.
Тут еще есть проблема в понимании определения стабов. Стаб - это затычка. Например, у тебя есть функция, которая требует 3 аргумента, но ты знаешь, что последний аргумент в данном тесте использоваться не будет вообще. И ты даешь этой функции стаб. Чем он проще - тем лучше. У стаба не должно быть никакой логики, он должен соотвествовать абсолютному минимум требований. allow receive - это не стаб, а полноценный мок с поведением. Стабы - это нормально, но они все равно используются довольно редко(и если тебе реально нужен стаб, то ты можешь его написать сам за минуту, без всяких мокинг либ). Моки - это не норма, а исключение, и должны использоваться еще реже, чем стабы.
>>28287
Сценарии должны звучать не как "компонент вернул true/false", а соотвествовать юзкейсам. Например, в контроллере у тебя были такие юзкейсы(и, соответственно, тесты для них)
a) Если регистрация закрыта, то API вернет ошибку 1
b) Если не проверить паспорт, то API вернет ошибку 2
c) Если не проверить еще что-то, то API вернет ошибку 3
d) Если регистрация открыта, паспорт и все остальное проверны, то API вернет что-то другое
... и т.д
Ты решил упростить контроллер и вынести пункты a-d в свою Policy. Для этого ты:
1) написал Policy
2) написал для нее тесты(по сути просто скопировал нужные тесткейсы из контроллера и подправил API).
3) Интегрировал Policy в контролер и убрал из контролера весь повторяющийся код
4) Прогнал все тесты для контролера, они должны быть зелеными.
5) Начинаешь убирать все повторяющиеся тесты внутри контроллера(эти тесты ты вынес в Policy на шаге 2). И вот тут важный момент - в контроллере нужно оставить тот минимум тестов, которые позволят тебе с уверенностью знать, что Policy контроллером на самом деле используется. Например, в контроллере остались тесты юзкейса а), юзкейса d) и нужный сетап для этих тестов.
6) Так как сетап повторяется и внутри тестов контроллера, и внутри тестов Policy, его логично и удобно вынести в общий модуль, который будет этими тестами использоваться
7) Опционально можно вынести оба повторяющихся теста в такой же модуль. Но можно и не выносить, если тесты очень простые и проверяют те юзкейсы, которые почти наверняка никогда не будут меняться.
Подобный процесс требует не сильно больше усилий, чем моканье, но при этом не привязывает твой код к текущей внутрней имплементации, и такие тесты будут ломаться только тогда, когда сломался реальный юзкейс, а не левый мок.
Это уже рельсопроблемы, тут ничего посоветовать не могу.
>Слабая связность - не сильвер буллет, ебал я в рот продираться через миллионы тонких классов.
Поэтому ты и пишешь вещи сверху-вниз, вынося в отдельные классы/паттерны/модули только тогда, когда это реально оправдано, улучшает читаемость или помогает внедрить изменение. И тесты в этом отлично помогают, если они конечно не замоканы.
>Стабов не нужно избегать, но пользоваться в ограниченном объёме.
Тут еще есть проблема в понимании определения стабов. Стаб - это затычка. Например, у тебя есть функция, которая требует 3 аргумента, но ты знаешь, что последний аргумент в данном тесте использоваться не будет вообще. И ты даешь этой функции стаб. Чем он проще - тем лучше. У стаба не должно быть никакой логики, он должен соотвествовать абсолютному минимум требований. allow receive - это не стаб, а полноценный мок с поведением. Стабы - это нормально, но они все равно используются довольно редко(и если тебе реально нужен стаб, то ты можешь его написать сам за минуту, без всяких мокинг либ). Моки - это не норма, а исключение, и должны использоваться еще реже, чем стабы.
>>28287
> А как тогда тестировать кейс, когда логика внутри тестируемого юнита зависит от результата другого юнита? Ну то есть как тогда проверить, два сценария: 1) Policy вернула true 2) Policy вернула false
Сценарии должны звучать не как "компонент вернул true/false", а соотвествовать юзкейсам. Например, в контроллере у тебя были такие юзкейсы(и, соответственно, тесты для них)
a) Если регистрация закрыта, то API вернет ошибку 1
b) Если не проверить паспорт, то API вернет ошибку 2
c) Если не проверить еще что-то, то API вернет ошибку 3
d) Если регистрация открыта, паспорт и все остальное проверны, то API вернет что-то другое
... и т.д
Ты решил упростить контроллер и вынести пункты a-d в свою Policy. Для этого ты:
1) написал Policy
2) написал для нее тесты(по сути просто скопировал нужные тесткейсы из контроллера и подправил API).
3) Интегрировал Policy в контролер и убрал из контролера весь повторяющийся код
4) Прогнал все тесты для контролера, они должны быть зелеными.
5) Начинаешь убирать все повторяющиеся тесты внутри контроллера(эти тесты ты вынес в Policy на шаге 2). И вот тут важный момент - в контроллере нужно оставить тот минимум тестов, которые позволят тебе с уверенностью знать, что Policy контроллером на самом деле используется. Например, в контроллере остались тесты юзкейса а), юзкейса d) и нужный сетап для этих тестов.
6) Так как сетап повторяется и внутри тестов контроллера, и внутри тестов Policy, его логично и удобно вынести в общий модуль, который будет этими тестами использоваться
7) Опционально можно вынести оба повторяющихся теста в такой же модуль. Но можно и не выносить, если тесты очень простые и проверяют те юзкейсы, которые почти наверняка никогда не будут меняться.
Подобный процесс требует не сильно больше усилий, чем моканье, но при этом не привязывает твой код к текущей внутрней имплементации, и такие тесты будут ломаться только тогда, когда сломался реальный юзкейс, а не левый мок.
>Да, но если внутри есть суб-директории без скоуп-модулей, то автолоадинг перестает работать
Это уже рельсопроблемы, тут ничего посоветовать не могу.
>>27286
Комментарий о том, что в питон встроены удобства для прямой работы с DI. В коментарих к коментарию пишут, что это не правда. То же и о руби. Я не понял, как инфа по ссылке отвечает на мой вопрос. Можешь подробнее?
Комментарий о том, что в питон встроены удобства для прямой работы с DI. В коментарих к коментарию пишут, что это не правда. То же и о руби. Я не понял, как инфа по ссылке отвечает на мой вопрос. Можешь подробнее?
>>28874
Тебе не нужен целый DI-фреймворк, как в джаве, если ты и так можешь инжектить что угодно и куда угодно в рантайме.
Тебе не нужен целый DI-фреймворк, как в джаве, если ты и так можешь инжектить что угодно и куда угодно в рантайме.
>>28895
Понял твою мысль, но инджэктить с десяток зависимостей в каждом вызове не удобно, для этого нужна та либа.
Понял твою мысль, но инджэктить с десяток зависимостей в каждом вызове не удобно, для этого нужна та либа.
>>24437 (OP)
Пиздец я рубист, у меня нет друзей
Пиздец я рубист, у меня нет друзей
>>28979
Возможно твоя проблема как раз в том, что тебе в принципе приходится инжектить по 10 зависимостей на вызов, а не в том, что это делать (внезапно) неудобно.
Возможно твоя проблема как раз в том, что тебе в принципе приходится инжектить по 10 зависимостей на вызов, а не в том, что это делать (внезапно) неудобно.
>>28808
В общем, если я тебя правильно понял, ты предлагаешь создавать соответствующие условия (контекст). И чтобы не делать это каждый раз - выносить в модули.
Но в этом и заключался мой изначальный вопрос в самом первом посте - как создавать сложные условия.
Я же с самого начала написал, что это либо DI/стабы ок, моки либо моделирование условий.
В общем, если я тебя правильно понял, ты предлагаешь создавать соответствующие условия (контекст). И чтобы не делать это каждый раз - выносить в модули.
Но в этом и заключался мой изначальный вопрос в самом первом посте - как создавать сложные условия.
Я же с самого начала написал, что это либо DI/стабы ок, моки либо моделирование условий.
>>28895
Вот тут уже не понятно: или мы под инжектом понимаем разные вещи или в чем разница-то между явой и руби?
опять другой анон
>если ты и так можешь инжектить что угодно и куда угодно в рантайме
Вот тут уже не понятно: или мы под инжектом понимаем разные вещи или в чем разница-то между явой и руби?
опять другой анон
>>28999
Так моки это и есть моделирование условий, просто с ними ты привязываешься к текущей имплементации, получая взамен только иллюзию, что якобы так будет проще поддерживать код.
>либо моделирование условий.
Так моки это и есть моделирование условий, просто с ними ты привязываешься к текущей имплементации, получая взамен только иллюзию, что якобы так будет проще поддерживать код.
>>28997
У тебя есть сервисоббджект который вызывает несколько других сервисобджектов, каждый из которых вызывает еще несколько. Вот внезапно и набирается с десяток зависимостей.
У тебя есть сервисоббджект который вызывает несколько других сервисобджектов, каждый из которых вызывает еще несколько. Вот внезапно и набирается с десяток зависимостей.
>>29055
И для чего именно тебе нужно инжектить зависимости в каждый из этих объектов? Я такой случай представить вообще не могу.
>>29001
Зависит от того, что именно ты инжектишь, куда, и зачем.
>>29006
В том, что в руби тебе не нужно хуячить никакую спецификацию для твоего DI(XML, аттрибуты и т.д), чтобы удовлетворить компилятор. Ты просто берешь и инжектишь без задней мысли.
И для чего именно тебе нужно инжектить зависимости в каждый из этих объектов? Я такой случай представить вообще не могу.
>>29001
Зависит от того, что именно ты инжектишь, куда, и зачем.
>>29006
В том, что в руби тебе не нужно хуячить никакую спецификацию для твоего DI(XML, аттрибуты и т.д), чтобы удовлетворить компилятор. Ты просто берешь и инжектишь без задней мысли.
>>25515
gem install ruby-progressbar
gem install ruby-progressbar
>>29064
На вход тебе приходят три параметра. Для каждого из них нужно сделать следующее: произвести вычисления, сохранить результат, отправить отчёт, всё это залогировать.
вычисление
сохранение
отчёт
логирование
И так три раза
Ты выносишь эту последовательность в отдельный сервис.
Вычислениями занимается также отдельный сервис.
Сохранением тоже, логированием тоже, и отчётом. Твоему модулю не нужно знать, с помощью чего будет происходить логирование, ему не нужно знать, куда будут сохраняться данные, по какому каналу отправлться отчёт.
Поэтому твой сервис на вход получает класс отвечающий за вычислени, класс отвечающий за логирование, класс отвечающий за сохранение, класс отвечающий за формирование отчета, класс отвечающий за его отправку.
И в твоем верхнеуровнем методе/контролере множество таких классов, которые вызывают методы других классов, вызывающих методы других классов.
>И для чего именно тебе нужно инжектить зависимости в каждый из этих объектов? Я такой случай представить вообще не могу.
На вход тебе приходят три параметра. Для каждого из них нужно сделать следующее: произвести вычисления, сохранить результат, отправить отчёт, всё это залогировать.
вычисление
сохранение
отчёт
логирование
И так три раза
Ты выносишь эту последовательность в отдельный сервис.
Вычислениями занимается также отдельный сервис.
Сохранением тоже, логированием тоже, и отчётом. Твоему модулю не нужно знать, с помощью чего будет происходить логирование, ему не нужно знать, куда будут сохраняться данные, по какому каналу отправлться отчёт.
Поэтому твой сервис на вход получает класс отвечающий за вычислени, класс отвечающий за логирование, класс отвечающий за сохранение, класс отвечающий за формирование отчета, класс отвечающий за его отправку.
И в твоем верхнеуровнем методе/контролере множество таких классов, которые вызывают методы других классов, вызывающих методы других классов.
>>29075
И что именно делает самый верхней модуль, если он ничего не знает, а только делегирует все задачи, сам не зная куда? Для чего он существует и почему ты не можешь убрать из него все инъекции и добавить эти зависимости напрямую? Чтобы настолько пиздецовые абстракции были оправданы, нужна очень сложная архитектура, в твоем примере ее нет.
И что именно делает самый верхней модуль, если он ничего не знает, а только делегирует все задачи, сам не зная куда? Для чего он существует и почему ты не можешь убрать из него все инъекции и добавить эти зависимости напрямую? Чтобы настолько пиздецовые абстракции были оправданы, нужна очень сложная архитектура, в твоем примере ее нет.
>>29083
Этим и занимается.
Добавил зависимости напрямую - усилил связанность классов. Привязал свой класс к другому классу. Это конец. Твой сервис уже сложнее использовать в другом контексте, потому что он содержит в себе контекст. Ты уже не можешь динамически выбирать способ отправки отчёта - он зашит в твоем модуле. Нет, конечно ты можешь в своём сервисе указать не класс, отвечающий за нотификацию, а класс, выбирающий способ нотификации. Да? Но как он будет выбирать. Ему какие-то данные нужны. Значит эти данные придется тащить внутрь твоего сервиса.
https://en.wikipedia.org/wiki/Coupling_(computer_programming)
Мой пример достаточен, для того, чтобы продемонстрировать идею, а умножить сложность в пару сотен раз ты и сам сможешь в своей голове, достаточно представить, что то, что я тебе описал - небольшая часть большого проекта. Она кажется простой, потому что вырвана из контекста. И я могу себе позволить вырвать её оттуда, потому что наш модуль ничего не знает о процессе формировани отчета и т.д. Отдельно он выглядит не таким уж и сложным, и реализовать его хочется просто, только это обманчивая простота.
>И что именно делает самый верхней модуль, если он ничего не знает, а только делегирует все задачи, сам не зная куда
Этим и занимается.
>Для чего он существует и почему ты не можешь убрать из него все инъекции и добавить эти зависимости напрямую?
Добавил зависимости напрямую - усилил связанность классов. Привязал свой класс к другому классу. Это конец. Твой сервис уже сложнее использовать в другом контексте, потому что он содержит в себе контекст. Ты уже не можешь динамически выбирать способ отправки отчёта - он зашит в твоем модуле. Нет, конечно ты можешь в своём сервисе указать не класс, отвечающий за нотификацию, а класс, выбирающий способ нотификации. Да? Но как он будет выбирать. Ему какие-то данные нужны. Значит эти данные придется тащить внутрь твоего сервиса.
https://en.wikipedia.org/wiki/Coupling_(computer_programming)
>Чтобы настолько пиздецовые абстракции были оправданы, нужна очень сложная архитектура, в твоем примере ее нет.
Мой пример достаточен, для того, чтобы продемонстрировать идею, а умножить сложность в пару сотен раз ты и сам сможешь в своей голове, достаточно представить, что то, что я тебе описал - небольшая часть большого проекта. Она кажется простой, потому что вырвана из контекста. И я могу себе позволить вырвать её оттуда, потому что наш модуль ничего не знает о процессе формировани отчета и т.д. Отдельно он выглядит не таким уж и сложным, и реализовать его хочется просто, только это обманчивая простота.
>>29088
Наркоман? Использовать сложнее как раз те вещи, которые требуют какого-то предварительного сетапа или кучи условий для их работы.
Или вместо дрочки DI ты можешь добавить выбор отправки отчета в обычное API своего модуля, например notify_via: :email.
Весь новый функционал и должен реализовываться самым глупым-прямолинейным-простым способом, который покрывает только необходимый минимум условий. Усложнять этот функционал лишними абстракциями нужно только по мере надобности: когда падает читабельность, когда сложно добавить новый юзкейс и т.д. То, что ты описываешь - это классический оверинжинирнг, который приводит к лютой лапше. Декаплинга, паттерны и прочие абстракции - это не вселенское добро, которое нужно юзать при любом пуке, у них есть свои, часто немаленькие, трейдофы.
>Добавил зависимости напрямую - усилил связанность классов. Привязал свой класс к другому классу. Это конец. Твой сервис уже сложнее использовать
Наркоман? Использовать сложнее как раз те вещи, которые требуют какого-то предварительного сетапа или кучи условий для их работы.
>Ты уже не можешь динамически выбирать способ отправки отчёта - он зашит в твоем модуле.
Или вместо дрочки DI ты можешь добавить выбор отправки отчета в обычное API своего модуля, например notify_via: :email.
>Отдельно он выглядит не таким уж и сложным, и реализовать его хочется просто, только это обманчивая простота.
Весь новый функционал и должен реализовываться самым глупым-прямолинейным-простым способом, который покрывает только необходимый минимум условий. Усложнять этот функционал лишними абстракциями нужно только по мере надобности: когда падает читабельность, когда сложно добавить новый юзкейс и т.д. То, что ты описываешь - это классический оверинжинирнг, который приводит к лютой лапше. Декаплинга, паттерны и прочие абстракции - это не вселенское добро, которое нужно юзать при любом пуке, у них есть свои, часто немаленькие, трейдофы.
>>29094
И чем это отличается от передачи класса? Ты всё также передаешь параметр, только теперь тебе внутри еще нужен код, который твой email развернёт в класс.
Наркоман? В этом примере как раз таки по условию много условий, определяющих какой код будет выполнен, тебе в любом случае все придется параметризовывать.
В указанном примере надобность есть.
Ты меня троллируешь?
>Или вместо дрочки DI ты можешь добавить выбор отправки отчета в обычное API своего модуля, например notify_via: :email.
И чем это отличается от передачи класса? Ты всё также передаешь параметр, только теперь тебе внутри еще нужен код, который твой email развернёт в класс.
>Наркоман? Использовать сложнее как раз те вещи, которые требуют какого-то предварительного сетапа или кучи условий для их работы.
Наркоман? В этом примере как раз таки по условию много условий, определяющих какой код будет выполнен, тебе в любом случае все придется параметризовывать.
>Усложнять этот функционал лишними абстракциями нужно только по мере надобности
В указанном примере надобность есть.
Ты меня троллируешь?
>>29099
Он тебя не троллирует. Если тебя корёжит от захордкоженного класса, то предусмотри переопределение соотв. аттрибута в инициализаторе инъекциями, конфиг-классами, магией.
> Ты меня троллируешь?
Он тебя не троллирует. Если тебя корёжит от захордкоженного класса, то предусмотри переопределение соотв. аттрибута в инициализаторе инъекциями, конфиг-классами, магией.
как же я обожаю раби, серьезно, пописал немного на ноде - да, прикольно, но не то, сейчас опять пилю на рельсе - какая же она кайфовая, язык богов
>>29016
>>29064
Какой же ты демагог.
>>29083
И дилетант.
>>29094
Сука, еще и рельсо-магическо-головый. Типичный devise-style. Из этого сразу понятно насколько сложные вещи тебе приходилось делать, точнее не приходилось.
>>29094
Вот тут вынужден согласиться. Только не в кассу, речь не об этом.
>>29099
Он не тролирует, он похоже не очень разбирается. Эдакий эффективный аппер-интермидд, судя по тону в сеньоры стремящийся.
По теме: мне кажется такие ситуации можно решать каким-нибудь оркестратором. Вся задача которого будет в том, чтобы настроить зависимости - повесить лиснеры, в зависимости от опций прокинуть клиенты, адаптеры там всякие - и вызвать непосредственно рабочий объект. И как бы получится, что под капотом "движок" настраиваемый, а снаружи лаконичный интерфейс для вызова. И для каждого случая свой такой оркестратор, но чаще он будет один или с парочкой параметров.
Да, получается, что тут вроде как нет DI. Но блин, это же правда невозможно, определять туеву хучу зависимостей прямо при вызове, да еще и каждый раз.
Мне кажется DI это больше про глобальный конфиг, про инициализацию программы: хотим Pg или Mysql или CSV, ага? лол, такой логгер или другой, какой мидлвар использовать, с какой моделью работать (как девайс делает).
А что касается тестов, то мне кажется DI тут все равно не поможет. Ну вот есть механизм в dry-rb, ну и в чем разница замокаю я вызовы или буду использовать эту ебалу с зависимостями.
>>29064
>Так моки это и есть моделирование условий
>Зависит от... Ты просто берешь...
Какой же ты демагог.
>>29083
>Для чего он существует ... в твоем примере ее не
И дилетант.
>>29094
>например notify_via: :email
Сука, еще и рельсо-магическо-головый. Типичный devise-style. Из этого сразу понятно насколько сложные вещи тебе приходилось делать, точнее не приходилось.
>>29094
>Весь новый функционал и должен реализовываться самым глупым-прямолинейным-простым способом
>Усложнять этот функционал лишними абстракциями нужно только по мере надобности
Вот тут вынужден согласиться. Только не в кассу, речь не об этом.
>>29099
Он не тролирует, он похоже не очень разбирается. Эдакий эффективный аппер-интермидд, судя по тону в сеньоры стремящийся.
По теме: мне кажется такие ситуации можно решать каким-нибудь оркестратором. Вся задача которого будет в том, чтобы настроить зависимости - повесить лиснеры, в зависимости от опций прокинуть клиенты, адаптеры там всякие - и вызвать непосредственно рабочий объект. И как бы получится, что под капотом "движок" настраиваемый, а снаружи лаконичный интерфейс для вызова. И для каждого случая свой такой оркестратор, но чаще он будет один или с парочкой параметров.
Да, получается, что тут вроде как нет DI. Но блин, это же правда невозможно, определять туеву хучу зависимостей прямо при вызове, да еще и каждый раз.
Мне кажется DI это больше про глобальный конфиг, про инициализацию программы: хотим Pg или Mysql или CSV, ага? лол, такой логгер или другой, какой мидлвар использовать, с какой моделью работать (как девайс делает).
А что касается тестов, то мне кажется DI тут все равно не поможет. Ну вот есть механизм в dry-rb, ну и в чем разница замокаю я вызовы или буду использовать эту ебалу с зависимостями.
>>29099
Тем, что теперь твой клиент не знает ни о каких левых классах, а полагается только на публичное простое API
>>29808
И к чему ты это кукарекнул? Где тут хоть какая-то магия?
>И чем это отличается от передачи класса? Ты всё также передаешь параметр,
Тем, что теперь твой клиент не знает ни о каких левых классах, а полагается только на публичное простое API
>>29808
>Сука, еще и рельсо-магическо-головый. Типичный devise-style.
И к чему ты это кукарекнул? Где тут хоть какая-то магия?
>>29808
В 9 из 10 случаев объект пишет в стандартный логгер, на 10 раз тебе дали таск завернуть обращение, например, в телеграмм. Соответственно, 9 раз указывать логгер явно не нужно, ты его хардкодишь, как дефолтный. А на 10 случай пишешь: MyService.new(:customLogger => TelegaLogger.new).
Внедрение зависимости используется для понижения связости и переопределения частных случаев за счет повышения сцепленности (coupling).
Остальное комментировать не буду, тебе ещё много учится)
мимо недемагог
В 9 из 10 случаев объект пишет в стандартный логгер, на 10 раз тебе дали таск завернуть обращение, например, в телеграмм. Соответственно, 9 раз указывать логгер явно не нужно, ты его хардкодишь, как дефолтный. А на 10 случай пишешь: MyService.new(:customLogger => TelegaLogger.new).
Внедрение зависимости используется для понижения связости и переопределения частных случаев за счет повышения сцепленности (coupling).
Остальное комментировать не буду, тебе ещё много учится)
мимо недемагог
>>29944
Если говорить конкретно про пример логирования, то это решается немного другими приемами. Сувать такое в конструктор как-бы моветон.
И ты путаешь связность и зацепление (и по русски и по английски путаешь). Хотя возможно и понимаешь суть.
Сори, но ты-таки демагог.
Если говорить конкретно про пример логирования, то это решается немного другими приемами. Сувать такое в конструктор как-бы моветон.
И ты путаешь связность и зацепление (и по русски и по английски путаешь). Хотя возможно и понимаешь суть.
Сори, но ты-таки демагог.
>>29950
Ничего страшного, но я не буду пролжать общение, т.к. не увидел ни 1 аргумента с твоей стороны. Добрых выходных!
Ничего страшного, но я не буду пролжать общение, т.к. не увидел ни 1 аргумента с твоей стороны. Добрых выходных!
>>29952
Тут несколько людей независимо общаются, и никто не подписывается.
Какие аргументы тебе нужны? Я выше привёл хорошие аргументы, которые ты или кто-то другой разбил в пух и прах ответами "слишком сложная структура" и "логирование через стандартный логгер". Пример нужен был для наглядной демонстрации идеи, а ты стал доебываться до синих занавесок.
В споре может быть и рождается истина, но не в таком. Я начал с тобой диалог, потому что думал, что у тебя есть какая-то новая, интересная мне информация, а ты всего-то хочешь доказать, что ты прав, ну и хуй с тобой тогда. Эта беседа максимум тебе полезна.
>>29808
Этот DI нужен только для удобства. Ты все равно будешь мокать, но в этом случае моканье будет более комфортным. У тебя два варианта: либо воссоздавать всю структуру, добавлять в базу десятки объектов для одного теста, либо обмазываться стабами. Если это модульное тестирование - лучше всё стабить, а потом в интеграционном тестировании проверять связи между объектами и общую работоспособность создавая реальные объекты - никаких стабов.
Если ты используешь rspec, думаю, тебе стоит попробовать вынести создание double'ов в отдельный модуль. Сделать аналог FactoryBot, но только для double'ов. Так как у тебя моки и стабы повторяются по проекту, их надо куда-то вынести. У тебя в любом случае пердак будет гореть от тестов, DI, не панацея, он чуть упрощает этот процесс.
Тут несколько людей независимо общаются, и никто не подписывается.
Какие аргументы тебе нужны? Я выше привёл хорошие аргументы, которые ты или кто-то другой разбил в пух и прах ответами "слишком сложная структура" и "логирование через стандартный логгер". Пример нужен был для наглядной демонстрации идеи, а ты стал доебываться до синих занавесок.
В споре может быть и рождается истина, но не в таком. Я начал с тобой диалог, потому что думал, что у тебя есть какая-то новая, интересная мне информация, а ты всего-то хочешь доказать, что ты прав, ну и хуй с тобой тогда. Эта беседа максимум тебе полезна.
>>29808
>Ну вот есть механизм в dry-rb, ну и в чем разница замокаю я вызовы или буду использовать эту ебалу с зависимостями
Этот DI нужен только для удобства. Ты все равно будешь мокать, но в этом случае моканье будет более комфортным. У тебя два варианта: либо воссоздавать всю структуру, добавлять в базу десятки объектов для одного теста, либо обмазываться стабами. Если это модульное тестирование - лучше всё стабить, а потом в интеграционном тестировании проверять связи между объектами и общую работоспособность создавая реальные объекты - никаких стабов.
Если ты используешь rspec, думаю, тебе стоит попробовать вынести создание double'ов в отдельный модуль. Сделать аналог FactoryBot, но только для double'ов. Так как у тебя моки и стабы повторяются по проекту, их надо куда-то вынести. У тебя в любом случае пердак будет гореть от тестов, DI, не панацея, он чуть упрощает этот процесс.
>>29967
Хмм... это идея.
Правда не могу с ходу придумать, как это может выглядеть. А ты пробовал такое?
>Сделать аналог FactoryBot, но только для double'ов
Хмм... это идея.
Правда не могу с ходу придумать, как это может выглядеть. А ты пробовал такое?
>>29972
Да. В spec/support/ кидаешь все свои вспомогательные классы. Например, есть определенное состояние, достаточно типовое, встречающиеся много раз в проекте, но для того, чтобы его получить, тебе нужно создать несколько различных записей в бд, установить какие-то настройки, добавить какие-то стабы и т.д. Ты это все вытаскиваешь в один метод и потом спокойно вызываешь его в тестах.
Да. В spec/support/ кидаешь все свои вспомогательные классы. Например, есть определенное состояние, достаточно типовое, встречающиеся много раз в проекте, но для того, чтобы его получить, тебе нужно создать несколько различных записей в бд, установить какие-то настройки, добавить какие-то стабы и т.д. Ты это все вытаскиваешь в один метод и потом спокойно вызываешь его в тестах.
>>29950
Это кто тебе сказал? Если тебе нужен кастомный логгер внутри одного отдельного объекта, то его легче всего засунуть в конструктор этого объекта, а не придумывать заранее целую систему инъекций или хуй знает чего.
>Сувать такое в конструктор как-бы моветон.
Это кто тебе сказал? Если тебе нужен кастомный логгер внутри одного отдельного объекта, то его легче всего засунуть в конструктор этого объекта, а не придумывать заранее целую систему инъекций или хуй знает чего.
язык хороший,только гайдов маловато
114 Кб, 1024x661Ну что пачаны, дерзайте
>>30312
че странного, хотелось бы пропустить этот этап, кучу гемов перепрописывать сначала для 5, а потом для 6
че странного, хотелось бы пропустить этот этап, кучу гемов перепрописывать сначала для 5, а потом для 6
>>30497
нет,ложка более универсальна
нет,ложка более универсальна
339 Кб, 563x805Посоветуйте легковесную IDE или редактор с хорошей поддержкой Ruby.
>>34097
Хорошей поддержки руби не существует в природе, язык слишком динамичный для этого. Бери или vscode или atom. Мне лично atom больше нравится, хотя в последнее время его стало модно обсирать и популярность у него уже не та. Но в плане UX он наголову выше vscode как по мне. Один мега уебищный поиск в vscode чего стоит. vscode использую только на домашнем ноуте, так как atom на нем тормозит.
Хорошей поддержки руби не существует в природе, язык слишком динамичный для этого. Бери или vscode или atom. Мне лично atom больше нравится, хотя в последнее время его стало модно обсирать и популярность у него уже не та. Но в плане UX он наголову выше vscode как по мне. Один мега уебищный поиск в vscode чего стоит. vscode использую только на домашнем ноуте, так как atom на нем тормозит.
>>34658
Хз, я всё ещё на работке
Хз, я всё ещё на работке
Анонч, где помониторить джобки, окромя хх и моегокруга?
>>35154
инфа 100ка?
инфа 100ка?
>>35062
На уровне RubyMine нельзя. Но как по мне, даже в RubyMine оно хоть и лучше конкурентов, все равно настолько уебищное, что смысла в нем нету. Так что я просто использую autocomplete-plus (установлен по-дефолту) с включенным дополнением из всех открытых файлов. На работе проект около 100к LOC и 500 моделей и мне этого хватает.
На уровне RubyMine нельзя. Но как по мне, даже в RubyMine оно хоть и лучше конкурентов, все равно настолько уебищное, что смысла в нем нету. Так что я просто использую autocomplete-plus (установлен по-дефолту) с включенным дополнением из всех открытых файлов. На работе проект около 100к LOC и 500 моделей и мне этого хватает.
>>35485
Первая наследуется, а вторая нет. И, соответственно, если ты поменяешь переменную класса в сабклассе, то она поменяется и в родителе. Сложно представить зачем такое поведение вообще может понадобится, за 5 лет я вообще ни разу не видел переменных класса в продакшен коде, только инстансовые переменные класса.
Первая наследуется, а вторая нет. И, соответственно, если ты поменяешь переменную класса в сабклассе, то она поменяется и в родителе. Сложно представить зачем такое поведение вообще может понадобится, за 5 лет я вообще ни разу не видел переменных класса в продакшен коде, только инстансовые переменные класса.
>>35202
То есть ничего подобного IntelliSense для Руби нет? Печаль. Сделаю, как ты написал. Спасибо.
То есть ничего подобного IntelliSense для Руби нет? Печаль. Сделаю, как ты написал. Спасибо.
>>35126
Вот это хороший вопрос на самом деле.
Я недавно сам стал задумываться о плюсах и минусах рельс. Я кроме рельс ничего не видел, а очень хотелось бы сравнить с джанго. Было бы здорово поговорить с человеком который плотно поработал и с тем и с другим.
Вообще очень заебала рельсо-магия и упорное отрицание сообществом ооп-практик и солида. А в питоне и джанго я сылашал с этим получше и есть модульность, которой так не хватает рельсам.
С другой стороны я слышал что они там отсталые все, обратно-совместимые с неудобными миграциями и всякое такое.
Вот это хороший вопрос на самом деле.
Я недавно сам стал задумываться о плюсах и минусах рельс. Я кроме рельс ничего не видел, а очень хотелось бы сравнить с джанго. Было бы здорово поговорить с человеком который плотно поработал и с тем и с другим.
Вообще очень заебала рельсо-магия и упорное отрицание сообществом ооп-практик и солида. А в питоне и джанго я сылашал с этим получше и есть модульность, которой так не хватает рельсам.
С другой стороны я слышал что они там отсталые все, обратно-совместимые с неудобными миграциями и всякое такое.
>>36010
фреймворк многие велосипедные места сделал за тебя,высокий уровень абстракции.
минус-хуже с тонкой настройкой
фреймворк многие велосипедные места сделал за тебя,высокий уровень абстракции.
минус-хуже с тонкой настройкой
>>36010
Функционал, который работает просто-таки магическим образом, принцип работы тщательно спрятан за условными договоренностями и в самых неожиданных местах, который сильно опирается на контекст (чтобы все лишнее спрятать) и который сложно/нельзя кастомизировать.
Как пример devise. Хорошее коробочное решение, до тех пор, пока не понадобится что-то поменять.
Разные acts_as_*, многочисленные магические DSL, всякие договоренности о том что :symbol работает так, а 'simbol' иначе, всякие охуевшие хуки при наследовании/включении/расширении.
Причем часто это очень хуево сделано под капотом. Авторы предусматривают какой-то один очень тупой сценарий и даже при желании нельзя изменить поведение.
Включаешь какой-нибудь auditable (трекает изменения моделей) и пишешь в модели `audit :phone, :email, ...`. А потом задумаваешься, а что, это стало быть во всех моделях этот функционал проинжектен? Да блять, они тупо расширили ЭктивРекорд. Потом такой думаешь, ну ок, я как-нибудь сам оберну треканье, тем более мне это не в контексте самой модели нужно сделать, дайте мне тот класс, который за это отвечает. А хуй тебе - смотришь, а там блять просто лапша методов, которая тупо инжектится в модель, это даже не сервис-обджект. И начинаешь, понимать, почему они написали какую-то ебалу для того чтобы переопределить current_user - потому что там все сплошь контекстно-зависимое.
Хотя либа полезная и по сути очень простая. Но эта ебаная магия головного мозга в головах у рейлс-сообщества им не позволяет создавать модульный, расширяемый, переиспользуемый код.
Функционал, который работает просто-таки магическим образом, принцип работы тщательно спрятан за условными договоренностями и в самых неожиданных местах, который сильно опирается на контекст (чтобы все лишнее спрятать) и который сложно/нельзя кастомизировать.
Как пример devise. Хорошее коробочное решение, до тех пор, пока не понадобится что-то поменять.
Разные acts_as_*, многочисленные магические DSL, всякие договоренности о том что :symbol работает так, а 'simbol' иначе, всякие охуевшие хуки при наследовании/включении/расширении.
Причем часто это очень хуево сделано под капотом. Авторы предусматривают какой-то один очень тупой сценарий и даже при желании нельзя изменить поведение.
Включаешь какой-нибудь auditable (трекает изменения моделей) и пишешь в модели `audit :phone, :email, ...`. А потом задумаваешься, а что, это стало быть во всех моделях этот функционал проинжектен? Да блять, они тупо расширили ЭктивРекорд. Потом такой думаешь, ну ок, я как-нибудь сам оберну треканье, тем более мне это не в контексте самой модели нужно сделать, дайте мне тот класс, который за это отвечает. А хуй тебе - смотришь, а там блять просто лапша методов, которая тупо инжектится в модель, это даже не сервис-обджект. И начинаешь, понимать, почему они написали какую-то ебалу для того чтобы переопределить current_user - потому что там все сплошь контекстно-зависимое.
Хотя либа полезная и по сути очень простая. Но эта ебаная магия головного мозга в головах у рейлс-сообщества им не позволяет создавать модульный, расширяемый, переиспользуемый код.
>>36054
Ты прав, но этот рак давно уже распознали и большая часть комьюнити старается с ним бороться. Вместо devise есть sorcery. Audited пишется в 50 строчек под себя или вообще на триггерах делается paper_trail, кстати, погибче, посмотри в его сторону. А за попытку подключить всякие acts_as_huita в любой нормальной команде тебя в момент обоссут с ног до головы.
Ты прав, но этот рак давно уже распознали и большая часть комьюнити старается с ним бороться. Вместо devise есть sorcery. Audited пишется в 50 строчек под себя или вообще на триггерах делается paper_trail, кстати, погибче, посмотри в его сторону. А за попытку подключить всякие acts_as_huita в любой нормальной команде тебя в момент обоссут с ног до головы.
>>36113
Не знаю я, мне кажется этот багаж еще долго будет тянуться за рельсами. Да и сами рельсы и сам DHH этому крайне способствуют. Пожалуйста, полюбуйтесь - https://api.rubyonrails.org/classes/ActiveRecord/Suppressor.html.
Алсо, покажите мне, пожалуйста, команды, где обоссут за такой код, хочу туда устроиться.
Не знаю я, мне кажется этот багаж еще долго будет тянуться за рельсами. Да и сами рельсы и сам DHH этому крайне способствуют. Пожалуйста, полюбуйтесь - https://api.rubyonrails.org/classes/ActiveRecord/Suppressor.html.
Алсо, покажите мне, пожалуйста, команды, где обоссут за такой код, хочу туда устроиться.
>>36139
Да, это так. Вообще я был бы рад, если бы DHH ушел уже из рельс и перестал всякую хуиту пихать в них. Suppressor, кстати, мой любимый пример подобной хуиты от DHH. Но и других хватает: только из-за него sprockets до сих не выпили, в 6 рельсах зачем-то впихнут ActionText в core, почему нельзя было сделать это просто отдельным гемом для интеграции с npm пакетом (trix) не понятно, продвижение идеи, что если распихать жирную модель по concerns, то она типа перестанет быть жирной.
Данон же. Но вообще большинство приличных контор в ДС пишущих на руби: поток, рокет, инстамарт, whelly, маил, марсиане хоть я и не люблю этих ЧСВшных пидоров. И ты всегда можешь спросить на собеседование про проект же, если окажется, что там fat models по 1к+ строк, то просто откажешься и все.
>Не знаю я, мне кажется этот багаж еще долго будет тянуться за рельсами
Да, это так. Вообще я был бы рад, если бы DHH ушел уже из рельс и перестал всякую хуиту пихать в них. Suppressor, кстати, мой любимый пример подобной хуиты от DHH. Но и других хватает: только из-за него sprockets до сих не выпили, в 6 рельсах зачем-то впихнут ActionText в core, почему нельзя было сделать это просто отдельным гемом для интеграции с npm пакетом (trix) не понятно, продвижение идеи, что если распихать жирную модель по concerns, то она типа перестанет быть жирной.
>Алсо, покажите мне, пожалуйста, команды, где обоссут за такой код, хочу туда устроиться.
Данон же. Но вообще большинство приличных контор в ДС пишущих на руби: поток, рокет, инстамарт, whelly, маил, марсиане хоть я и не люблю этих ЧСВшных пидоров. И ты всегда можешь спросить на собеседование про проект же, если окажется, что там fat models по 1к+ строк, то просто откажешься и все.
>>36174
Поток Rоток, как там, Канаева уволили? хуй знает. Судя по описанию вакансии там разброд и шатание. Драй-рб блять. Эликсир, которого будет больше. Короче позатащили чего смогли и не знаю что с этим делать.
Рокет, инстамарт как-то неинтересно совсем.
Wheely вообще не рельсовые насколько я знаю. Когда я туда собеседовался года два назад, они мне показались довольно деревянными. У нас монга, а зачем выбрали - ну исторически так сложилось, у нас синатра и мы только недавно начали использовать сериалайзеры для ответов в апишке и тп. То есть рельсы им на каком-то идеологическом уровне не нравятся, но при этом своих велосипедов они сделать тоже не умеют. Легаси-код, легаси-задачи. А сейчас насколько я знаю они уже полиглоты стали, микросервисы там.
Марсин боюсь, они какие-то крутые слишком. Ну и удаленщики, а я так не умею.
А что майл? У них же вроде нет рубишных проектов?
>Но вообще большинство приличных контор в ДС пишущих на руби: поток, рокет, инстамарт, whelly, маил, марсиан
Поток Rоток, как там, Канаева уволили? хуй знает. Судя по описанию вакансии там разброд и шатание. Драй-рб блять. Эликсир, которого будет больше. Короче позатащили чего смогли и не знаю что с этим делать.
Рокет, инстамарт как-то неинтересно совсем.
Wheely вообще не рельсовые насколько я знаю. Когда я туда собеседовался года два назад, они мне показались довольно деревянными. У нас монга, а зачем выбрали - ну исторически так сложилось, у нас синатра и мы только недавно начали использовать сериалайзеры для ответов в апишке и тп. То есть рельсы им на каком-то идеологическом уровне не нравятся, но при этом своих велосипедов они сделать тоже не умеют. Легаси-код, легаси-задачи. А сейчас насколько я знаю они уже полиглоты стали, микросервисы там.
Марсин боюсь, они какие-то крутые слишком. Ну и удаленщики, а я так не умею.
А что майл? У них же вроде нет рубишных проектов?
>>36207
Ты похоже рынок вакансий в ДС лучше меня знаешь. Я сам уже 2 с лишним года на удаленке на иностранную контору работаю и не особо в курсе рыночка. До этого в двух относительно ноу-нейм конторах работал в ДС и уже тогда там никаких acts_as не было, так что думал, что уж крупных командах таких проблем точно не должно быть.
Да я под офигел от их списка "желательных" языков, когда они в последний раз меня звали - ruby/go/js/scala/python.
Сейчас вакансия в платежку висит (+ go), geekbrains да зашквар лютый, я знаю у них на руби, помню в прошлом году еще что-то видел.
Рокет по-моему интересным может быть, интересно же как вся эта банковская кухня работает. Но слышал, что у них ехал овертайм через овертайм.
Ты похоже рынок вакансий в ДС лучше меня знаешь. Я сам уже 2 с лишним года на удаленке на иностранную контору работаю и не особо в курсе рыночка. До этого в двух относительно ноу-нейм конторах работал в ДС и уже тогда там никаких acts_as не было, так что думал, что уж крупных командах таких проблем точно не должно быть.
>А сейчас насколько я знаю они уже полиглоты стали, микросервисы там.
Да я под офигел от их списка "желательных" языков, когда они в последний раз меня звали - ruby/go/js/scala/python.
>А что майл? У них же вроде нет рубишных проектов?
Сейчас вакансия в платежку висит (+ go), geekbrains да зашквар лютый, я знаю у них на руби, помню в прошлом году еще что-то видел.
Рокет по-моему интересным может быть, интересно же как вся эта банковская кухня работает. Но слышал, что у них ехал овертайм через овертайм.
>>36709
я реалист
я реалист
Блять, хули вы так мало постите суки. Я уже заебался тред обновлять - нихуя блять нет новых постов. Что вы за уебки блять такие.
>>37467
А вот интересно, все рубисты рашки тут сидят (ну или периодически заходят)? Ведь время от времени ололокают все, кого я знаю.
А вот интересно, все рубисты рашки тут сидят (ну или периодически заходят)? Ведь время от времени ололокают все, кого я знаю.
>>37480
Думаю и пяти процентов не наберётся. У нас на проекте из 5 рубистов максимум ещё один чел в курсе про борды.
Думаю и пяти процентов не наберётся. У нас на проекте из 5 рубистов максимум ещё один чел в курсе про борды.
>>37480
Тут нечего делать нормальным рубистам. Тред для них совершенно бесполезен, разве что от скуки зайти и что-то написать, поэтому тут так вяло.
Тут нечего делать нормальным рубистам. Тред для них совершенно бесполезен, разве что от скуки зайти и что-то написать, поэтому тут так вяло.
>>37536
а начинающим тем более
а начинающим тем более
>>37536
Где вообще русскоязычное комьюнити рубистов сидит? А то я вроде в руби уже давно, но с местным комьюнити, не считая rails club, почти и не контактировал никогда.
Где вообще русскоязычное комьюнити рубистов сидит? А то я вроде в руби уже давно, но с местным комьюнити, не считая rails club, почти и не контактировал никогда.
>>37569
ну и чем он хорощ?
ну и чем он хорощ?
>>37592
Все по Фрейду, хаха.
Значит правду про вас говорят.
Да и картинка в оппосте строго по дедушке :3
>по настоящему дружного
>по настоящему
Все по Фрейду, хаха.
Значит правду про вас говорят.
Да и картинка в оппосте строго по дедушке :3
>>37649
Да не стесняйся ты так, сладкий, сейчас быть таким даже модно и молодежно :3
Да не стесняйся ты так, сладкий, сейчас быть таким даже модно и молодежно :3
>>37569
Не знаю, да и какая разница? Обсуждать нечего. Руби очень простой язык. Задачи крайне однотипные. Большинство проблем решаются выбором правильного инструмента (гема, вебсервера, базы данных). Расти как рубисту некуда, потому что большая часть нужных технологий, умение работать с которыми повышает твою ценность на рынке, не привязана к какому-то конкретному языку.
Не знаю, да и какая разница? Обсуждать нечего. Руби очень простой язык. Задачи крайне однотипные. Большинство проблем решаются выбором правильного инструмента (гема, вебсервера, базы данных). Расти как рубисту некуда, потому что большая часть нужных технологий, умение работать с которыми повышает твою ценность на рынке, не привязана к какому-то конкретному языку.
>>37685
Да, но мы же при этом используем сруби. И могли бы обсуждать инструменты, практики, подходы именно в контексте работы в рубях.
Да, но мы же при этом используем сруби. И могли бы обсуждать инструменты, практики, подходы именно в контексте работы в рубях.
Хочу заняться backend разработкой. Какие перспективы меня ждут в ruby? Или лучше выбрать тот же php или node.js, питон?
>>39263
Сначала будет болеть, но потом привыкнешь и станет нравиться.
>Какие перспективы меня ждут в ruby?
Сначала будет болеть, но потом привыкнешь и станет нравиться.
Блин, посоны, я не мог этим не поделиться - https://hh.ru/vacancy/29861666
Разработчик Raby on Rails
от 80 000 до 100 000 руб. до вычета НДФЛ
ОАО Точных Приборов, НИИ
Разработчик Raby on Rails
от 80 000 до 100 000 руб. до вычета НДФЛ
ОАО Точных Приборов, НИИ
>Обязанности: Разработка программного решения, предназначенного для:
>-развертывания и управления сетевой инфраструктурой (FOREMAN,DNS,FREEIPA,TETR,DHCP и т.д);
>- развертывания и управления функционированием программного обеспечения;
>- развертывания серверов/рабочих станций (bare metal) и виртуальных машин различных провайдеров виртуализации;
>-мониторинга работоспособности аппаратного и программного обеспечения;
>-централизованного журналирования событий в работе аппаратного и программного обеспечения,
>
>Требования:
>-Опыт RoR-разработки от года
>-знания HTML/CSS,JavaScript, CoffeeScript,jQuery, Slim,Sass
>- Умение писать тесты Rspec, Capybara
>-Знание gem`ов Devise,Pundit,Sidekiq,
>-Плюсом будет решение задач по администрированию Linux, базовые знания по сетям. виртуализации и автоматизации разработки и развертывания ПО, окончание курсов по RoR.
>
>Условия: На предприятии имеется своя медсанчасть, профком, турклуб. Работа с 9.00 до 17.40,
>Выходные -суббота, воскресенье. Оплата труда -два раза в месяц
Парни, если кто-то работал или как-то знаком с этими конторами, расскажите. Сижу смотрю вакансии и за их формальным описанием сложно понять что от них ждать.
Qlean.Стирка
AMarkets
OVERTEAM
PiRL Ventures
Лэндинг Солюшн Групп aka CashWagon
Центр недвижимости от Сбербанка, ДомКлик
TalentTech
Рево-технологии
Бизнес партнер
inShopper, Mail.Ru Group
Qlean.Стирка
AMarkets
OVERTEAM
PiRL Ventures
Лэндинг Солюшн Групп aka CashWagon
Центр недвижимости от Сбербанка, ДомКлик
TalentTech
Рево-технологии
Бизнес партнер
inShopper, Mail.Ru Group
>>39263
никакие
никакие
>>39368
Прикольно так-то, для дауншифтинга самое оно, после смены с михалычем и петровичем в подсобке прибухнуть.
Прикольно так-то, для дауншифтинга самое оно, после смены с михалычем и петровичем в подсобке прибухнуть.
>>40035
Это тип данных, у которого реализованы 3 функции (return, join и bind) которые должны подчиняться определенным законам. По ссылке не монада, там этих функций вообще нет.
Это тип данных, у которого реализованы 3 функции (return, join и bind) которые должны подчиняться определенным законам. По ссылке не монада, там этих функций вообще нет.
>>40499
ну типа массив вычислений
ну типа массив вычислений
>>40475
Что-то ты придумываешь.
https://en.wikipedia.org/wiki/Monad_(category_theory)
>Это тип данных, у которого реализованы 3 функции (return, join и bind)
Что-то ты придумываешь.
https://en.wikipedia.org/wiki/Monad_(category_theory)
>>41009
По ссылке нет упоминаний никаких методов. Я написал код изучая книгу по теории категорий. Если есть замечания к коду с точки зрения терката, мне интересно.
По ссылке нет упоминаний никаких методов. Я написал код изучая книгу по теории категорий. Если есть замечания к коду с точки зрения терката, мне интересно.
>>41184
Коротко не объяснишь, если правда интересно, то читай http://learnyouahaskell.com/chapters. Если лень читать все, то можешь попробовать прочесть только 11 и 12 главу, получится или нет зависит от уровня твоего знакомства с функциональщиной.
Хуиту.
Не нужно, как и все остальные монадки в языках без компилятора, которой бы проверял за тобой, что ты не обосрался.
>объясните мне что это такое
Коротко не объяснишь, если правда интересно, то читай http://learnyouahaskell.com/chapters. Если лень читать все, то можешь попробовать прочесть только 11 и 12 главу, получится или нет зависит от уровня твоего знакомства с функциональщиной.
>что он там написал
Хуиту.
>зачем оно нужно?
Не нужно, как и все остальные монадки в языках без компилятора, которой бы проверял за тобой, что ты не обосрался.
>>41189
Ну камон, анон написал там 30 строк, я не верю, что чтобы понять смысл нужно прям идти функциональщину и теорию категорий учить.
>Коротко не объяснишь
Ну камон, анон написал там 30 строк, я не верю, что чтобы понять смысл нужно прям идти функциональщину и теорию категорий учить.
>>41194
Ты понимаешь про что я. Нахуй он эту ебалу написал, в чем прикол, зачем называть какими-то монадами структуру c флагом success/failure?
Ты понимаешь про что я. Нахуй он эту ебалу написал, в чем прикол, зачем называть какими-то монадами структуру c флагом success/failure?
79 Кб, 540x960>>41197
Ты хочешь понять термин из теории категорий, но не хочешь изучать теорию категорий.
Ты хочешь понять термин из теории категорий, но не хочешь изучать теорию категорий.
>>41192
Понимаешь ли, ты задал два вопроса:
На этот просто ответить. Это монада Either хотя я согласен с аноном выше, что у нее должно быть хотя бы еще пару методов, что бы таковой называться.
На этот вопрос ответить намного сложнее. Если очень коротко, то нужны они для того что бы безопасно и выразительно описывать сложные операции в языках с развитой системой типов. Так как в руби нету развитой системы типов, а уж о безопасности без компилятора тем более речи идти не может, то в руби они не нужны. Зачем они нужны в том же хаскеле читай по ссылке в моем предыдущем посте.
Понимаешь ли, ты задал два вопроса:
>Что это?
На этот просто ответить. Это монада Either хотя я согласен с аноном выше, что у нее должно быть хотя бы еще пару методов, что бы таковой называться.
>Зачем это?
На этот вопрос ответить намного сложнее. Если очень коротко, то нужны они для того что бы безопасно и выразительно описывать сложные операции в языках с развитой системой типов. Так как в руби нету развитой системы типов, а уж о безопасности без компилятора тем более речи идти не может, то в руби они не нужны. Зачем они нужны в том же хаскеле читай по ссылке в моем предыдущем посте.
>>41196
Насколько я понимаю он тоже перезагружает весь проект целиков каждый раз. Этим и не подходит, слишком медленно.
Насколько я понимаю он тоже перезагружает весь проект целиков каждый раз. Этим и не подходит, слишком медленно.
>>41200
Я, честно говоря, еще не пробовал Ханами в работе вообще. Смотрел доки, примеры кода. После "магии" рельсов и идей поехавшего dhh-а Ханами выглядит интересно. Сейчас разбираюсь с ROM-rb чтобы им заменить сраный ActiveRecord, а после вместо рельсов - Ханами. А может быстрее в Эликсир перекачусь. В мире руби проекты практически все на рельсах, в Эликсир перекатиться может быть проще чем в Ханами.
Я, честно говоря, еще не пробовал Ханами в работе вообще. Смотрел доки, примеры кода. После "магии" рельсов и идей поехавшего dhh-а Ханами выглядит интересно. Сейчас разбираюсь с ROM-rb чтобы им заменить сраный ActiveRecord, а после вместо рельсов - Ханами. А может быстрее в Эликсир перекачусь. В мире руби проекты практически все на рельсах, в Эликсир перекатиться может быть проще чем в Ханами.
>>41199
Ладно, буду считать, что монады это что-то типа гипотезы Пуанкаре и понять ее без предварительного изучения каких-то там разделов математики невозможно.
Ладно, буду считать, что монады это что-то типа гипотезы Пуанкаре и понять ее без предварительного изучения каких-то там разделов математики невозможно.
>>41202
В реальных проектах на рельсах опытные люди стараются просто не использовать совсем хуевые части AR, типа всякие suppress, before/after_save/create/etc, десятков методов для сохранения объектов в базу только save, максимум еще update, стараются по минимуму добавлять методы в модели, некоторые идут дальше и не используют валидации и scope. Webpacker вместе с assets pipeline, тоже сразу на помоечку отправляется, благо это можно сразу в rails new указать. Остальные части рельс вполне годно сделаны как по мне.
Эликсир с фениксом в целом годные, но там своей хуиты тоже хватает.
В реальных проектах на рельсах опытные люди стараются просто не использовать совсем хуевые части AR, типа всякие suppress, before/after_save/create/etc, десятков методов для сохранения объектов в базу только save, максимум еще update, стараются по минимуму добавлять методы в модели, некоторые идут дальше и не используют валидации и scope. Webpacker вместе с assets pipeline, тоже сразу на помоечку отправляется, благо это можно сразу в rails new указать. Остальные части рельс вполне годно сделаны как по мне.
Эликсир с фениксом в целом годные, но там своей хуиты тоже хватает.
>>41206
Спасибо, опытный человек, что поделился своей мудростью. Кроме suppress, про который знает каждая собака, потому что про него в блогах писали, есть еще много мест где ты будешь тратить время на борьбу с рельсами, а не создание ценного кода.
Спасибо, опытный человек, что поделился своей мудростью. Кроме suppress, про который знает каждая собака, потому что про него в блогах писали, есть еще много мест где ты будешь тратить время на борьбу с рельсами, а не создание ценного кода.
>>41209
Ну-ка, например!
Назови такие места и не забудь провести параллель с ханамями, где ты будешь тратить время на написание велосипедов.
Вообще-то проблема рельс не техническая, а идеологическая.
Ну-ка, например!
Назови такие места и не забудь провести параллель с ханамями, где ты будешь тратить время на написание велосипедов.
Вообще-то проблема рельс не техническая, а идеологическая.
>>41218
Предыдущий пост другой анон написал. Но я с ним согласен. Пишу рельсо-код каждый день и ни с чем не борюсь. Реально единственная неслишком хорошо сделанная часть рельс это AR из-за слишком большого API. Но если использовать адекватное подмножество AR, то рельсы все так же охуенны. Не знаю с чем можно бороться в остальных частях фреймворка.
Что ты так полыхнул-то на ровном месте, я же не один suppress указал.
Предыдущий пост другой анон написал. Но я с ним согласен. Пишу рельсо-код каждый день и ни с чем не борюсь. Реально единственная неслишком хорошо сделанная часть рельс это AR из-за слишком большого API. Но если использовать адекватное подмножество AR, то рельсы все так же охуенны. Не знаю с чем можно бороться в остальных частях фреймворка.
Что ты так полыхнул-то на ровном месте, я же не один suppress указал.
>>41222
ActiveSupport. Monkey patching, monkey patching everywhere. View helpers. Осознанное стремление dhh-a привязать бизнес-логику к фреймворку. Утяжеление приложения из-за того, что в рельсу пихают всякое нинужное говно. inb4 сейчас расскажешь что всё решаемо
ActiveSupport. Monkey patching, monkey patching everywhere. View helpers. Осознанное стремление dhh-a привязать бизнес-логику к фреймворку. Утяжеление приложения из-за того, что в рельсу пихают всякое нинужное говно. inb4 сейчас расскажешь что всё решаемо
>>41239
Никогда, НИКОГДА не было необходимости засунуть туда больше трех методов. А когда было нужно, было охуенно удобно. Бугурта декораторо-головых не понимаю - никто ж не запрещает делать по другому. реально не понимаю, что все привязались к этим хелперам
Опять не понимаю бугурта. Что там такого плохо? Знаю из блогов концерны не нравятся людям. Ну я их никогда и не использую, например, пишу PORO. Расширения базовых классов охуенны. До того охуенны, что от раза к разу что-то мигрирует прямо в руби.
Нужно признать, что внутри движка кромешный ад, это правда. Но машина работает как часы и меня мало волнует как оно там внутри устроено.
Идеологические проблемы, это да. Это беда рельсовой экосистемы.
>View helpers
Никогда, НИКОГДА не было необходимости засунуть туда больше трех методов. А когда было нужно, было охуенно удобно. Бугурта декораторо-головых не понимаю - никто ж не запрещает делать по другому. реально не понимаю, что все привязались к этим хелперам
>ActiveSupport
Опять не понимаю бугурта. Что там такого плохо? Знаю из блогов концерны не нравятся людям. Ну я их никогда и не использую, например, пишу PORO. Расширения базовых классов охуенны. До того охуенны, что от раза к разу что-то мигрирует прямо в руби.
>Monkey patching
Нужно признать, что внутри движка кромешный ад, это правда. Но машина работает как часы и меня мало волнует как оно там внутри устроено.
>Осознанное стремление dhh-a привязать бизнес-логику к фреймворку
Идеологические проблемы, это да. Это беда рельсовой экосистемы.
>>41250
Когда занимаешься проектами уровня блог за 15 минут, это нормально.
>Но машина работает как часы и меня мало волнует как оно там внутри устроено
Когда занимаешься проектами уровня блог за 15 минут, это нормально.
>>41239
А что там плохого-то?
Ну давай рассказывай как ты каждый день борешься с present? у Object и second у Array. Я тоже, конечно, против money patching, но именно фреймворку по-моему позволительно добавить некоторые методы общего назначения в стандартную библиотеку. И как уже сказали выше некоторые из них кочуют в руби.
Согласен. Года 4 уже ничего кроме json рельсами не отдавал и как-то забыл об их существование просто.
Это чисто пропаганда от dhh. В самом коде рельс ничто тебя не заставляет так делать.
Srsly? Когда у тебя приложение с сотнями и тысячами классов, то пофиг уже на несколько десятков лишних классов от рельс. Да и чистое рельсовое приложение около 100 метров всего жрет, насколько я помню, вполне вменяемо.
>ActiveSupport
А что там плохого-то?
>Monkey patching, monkey patching everywhere
Ну давай рассказывай как ты каждый день борешься с present? у Object и second у Array. Я тоже, конечно, против money patching, но именно фреймворку по-моему позволительно добавить некоторые методы общего назначения в стандартную библиотеку. И как уже сказали выше некоторые из них кочуют в руби.
>View helpers
Согласен. Года 4 уже ничего кроме json рельсами не отдавал и как-то забыл об их существование просто.
>Осознанное стремление dhh-a привязать бизнес-логику к фреймворку
Это чисто пропаганда от dhh. В самом коде рельс ничто тебя не заставляет так делать.
>Утяжеление приложения из-за того, что в рельсу пихают всякое нинужное говно
Srsly? Когда у тебя приложение с сотнями и тысячами классов, то пофиг уже на несколько десятков лишних классов от рельс. Да и чистое рельсовое приложение около 100 метров всего жрет, насколько я помню, вполне вменяемо.
Gggg
если писать для себя-РОР лучший выбор?
>>41297
Вот это ты погорячился сейчас. А раз уж ляпнул кукарекнул, точнее, то будь добр, приведи пример из практики, когда тебя волновали внутренности движка.
>Когда занимаешься проектами уровня блог за 15 минут, это нормально.
Вот это ты погорячился сейчас. А раз уж ляпнул кукарекнул, точнее, то будь добр, приведи пример из практики, когда тебя волновали внутренности движка.
Ребят, вот тут вы пишете коллбеки зло, а что делать? Вот у меня так - есть поле completed_count, которое хранит количество записей в связанной модели, ну как из counter_cache, только условие тут кастомное, так как его высчитывать без коллбека при добавлении записи?
>>42389
Бизнес логику хранишь в сервисобджектах. Добавление записи в твою модель через отдельный сервис, в котором после добавления обновляется твой completed_count. Но в твоем случае я бы скорее всего забил и делал также, как и ты. Или еще хуже - хуйнул бы все через триггер в постгре.Я еще тот дебил.
Бизнес логику хранишь в сервисобджектах. Добавление записи в твою модель через отдельный сервис, в котором после добавления обновляется твой completed_count. Но в твоем случае я бы скорее всего забил и делал также, как и ты. Или еще хуже - хуйнул бы все через триггер в постгре.Я еще тот дебил.
>>42191
Э нет, не уводи в сторону. Приведи пример, когда это создало тебе проблему. Именно рельсовый движок, а не гемы и патчи от васянов.
>>42389
Колбеки зло, если их ответственность выходит за рамки объекта. Их можно (наверное, даже нужно) использовать, если они работают с внутренним состоянием объекта. Хороший пример - простановка дефолтного значения.
На счет счетчика хз, зависит от счетчика. Если случай простой, то я бы тоже сделал коллбеком.
>>42524
Научи. Как вы поддерживаете эти триггеры, помните о них, ну как вообще с ними работаете? В рельсах-то о таком не принято говорить.
Э нет, не уводи в сторону. Приведи пример, когда это создало тебе проблему. Именно рельсовый движок, а не гемы и патчи от васянов.
>>42389
Колбеки зло, если их ответственность выходит за рамки объекта. Их можно (наверное, даже нужно) использовать, если они работают с внутренним состоянием объекта. Хороший пример - простановка дефолтного значения.
На счет счетчика хз, зависит от счетчика. Если случай простой, то я бы тоже сделал коллбеком.
>>42524
>хуйнул бы все через триггер
Научи. Как вы поддерживаете эти триггеры, помните о них, ну как вообще с ними работаете? В рельсах-то о таком не принято говорить.
>>42595
Я подожду до завтрашнего вечера - почитаю, как тебя другие обольют говном, школьничек.
Я подожду до завтрашнего вечера - почитаю, как тебя другие обольют говном, школьничек.
>>42598
Заскринил тебе за щеку.
Заскринил тебе за щеку.
>>42590
Мы о них помним только потому, что периодически пьём курс витаминов, правильно питаемся, хорошо спим и занимаемся бегом.
Я существо ленивое, далекое от самосовершенствования, и стал заботиться о себе только после того, как пол дня потратил на выяснение "какого хуя". Хуя оказалось такого, что у нас в постгре триггеры наебенены по самые помидоры, а мы про это забыли. Еще говорят документация помогает, но я не хочу использовать костыли для мозга, слишком гордый для этого.
Триггеры в постгре - альтернатива коллбэкам в рельсах. Ящитаю так: если тебе нужно какую-то бизнес логику добавить в триггеры или коллбэки - тебе это не нужно. Пиши нормальную класс под это дело.
Если тебе нужно манипулировать какой-то информацией, которая более техническая, чем практическая (пример из вопроса анона про счетчик). то как ты это будешь делать - через триггер или коллбэк - разницы практически никакой. Главное где-то записывать, что они используются, чтобы все в проекте знали.
>Научи. Как вы поддерживаете эти триггеры, помните о них, ну как вообще с ними работаете? В рельсах-то о таком не принято говорить.
Мы о них помним только потому, что периодически пьём курс витаминов, правильно питаемся, хорошо спим и занимаемся бегом.
Я существо ленивое, далекое от самосовершенствования, и стал заботиться о себе только после того, как пол дня потратил на выяснение "какого хуя". Хуя оказалось такого, что у нас в постгре триггеры наебенены по самые помидоры, а мы про это забыли. Еще говорят документация помогает, но я не хочу использовать костыли для мозга, слишком гордый для этого.
Триггеры в постгре - альтернатива коллбэкам в рельсах. Ящитаю так: если тебе нужно какую-то бизнес логику добавить в триггеры или коллбэки - тебе это не нужно. Пиши нормальную класс под это дело.
Если тебе нужно манипулировать какой-то информацией, которая более техническая, чем практическая (пример из вопроса анона про счетчик). то как ты это будешь делать - через триггер или коллбэк - разницы практически никакой. Главное где-то записывать, что они используются, чтобы все в проекте знали.
>>42614
Весело у вас в рубиманямирке. А посоны из постгреса-то и не в курсе что триггеры зря делали лоооол.
>если тебе нужно какую-то бизнес логику добавить в триггеры - тебе это не нужно
Весело у вас в рубиманямирке. А посоны из постгреса-то и не в курсе что триггеры зря делали лоооол.
>>42789
За триггеры с бизнес-логикой обоссывать начали еще тогда, когда рельс даже не существовало.
За триггеры с бизнес-логикой обоссывать начали еще тогда, когда рельс даже не существовало.
>>42796
Рельсам с их расширяемостью на уровне блога за 15 минут и перформансом на уровне пожилой улитки конечно не понять зачем в реляционных бд существуют триггеры. Остаётся только обоссывать собственный ротешник.
Рельсам с их расширяемостью на уровне блога за 15 минут и перформансом на уровне пожилой улитки конечно не понять зачем в реляционных бд существуют триггеры. Остаётся только обоссывать собственный ротешник.
>>42789
Весело у тебя в джуномирке. Посоны из постгреса на то и из постгреса, что решают проблемы в постгресе. Различные подходы и решения не просто так стандартизированы. Ты можешь всё захуячить в триггерах, ты можешь 99% бизнес логики описать в хранимках (и есть одна компания, которая так сделала) - это будет нормально, если все знают, что делают и всех это устраивает. Но если часть делать так, часть делать эдак - рано или поздно все проебётся. Люди уходят, люди приходят, а нестандартные решения остаются и дорогие человекочасы тратятся на разбирательства.
Весело у тебя в джуномирке. Посоны из постгреса на то и из постгреса, что решают проблемы в постгресе. Различные подходы и решения не просто так стандартизированы. Ты можешь всё захуячить в триггерах, ты можешь 99% бизнес логики описать в хранимках (и есть одна компания, которая так сделала) - это будет нормально, если все знают, что делают и всех это устраивает. Но если часть делать так, часть делать эдак - рано или поздно все проебётся. Люди уходят, люди приходят, а нестандартные решения остаются и дорогие человекочасы тратятся на разбирательства.
>>42833
А кто сказал что триггеры предназначены для 99%/всей бизнес-логики.
А кто сказал что хранимки и триггеры не должны попадать в миграции и схему бд.
Плиз.
А кто сказал что триггеры предназначены для 99%/всей бизнес-логики.
А кто сказал что хранимки и триггеры не должны попадать в миграции и схему бд.
>джуномирке.
Плиз.
>>42844
Ты так говоришь, как будто бы это что-то плохое. Сказ наоборот о том, что все яйца нужно держать в одном лукошке, а не траспортировать в жопах курьеров по одному. Если у тебя часть бизнес логики в рельсах, часть в триггерах, чем в хранимках, часть в коллбэках, тебе будет очень трудно работать с этим кодом спустя годы.
Стартапер дохуя? У тебя в рельсах никогда не было несколько сотен миграций? Тебе нравится пялиться в schema.rb? У тебя, наверное, и коллег нет, или все они с большой любовью делают то же самое?
Техническая возмножность то, что ты хочешь делать есть, но это нихуя не удобно в большинстве случаев, и создает охуенно большое пространство для проблем.
>А кто сказал что триггеры предназначены для 99%/всей бизнес-логики.
Ты так говоришь, как будто бы это что-то плохое. Сказ наоборот о том, что все яйца нужно держать в одном лукошке, а не траспортировать в жопах курьеров по одному. Если у тебя часть бизнес логики в рельсах, часть в триггерах, чем в хранимках, часть в коллбэках, тебе будет очень трудно работать с этим кодом спустя годы.
>А кто сказал что хранимки и триггеры не должны попадать в миграции и схему бд
Стартапер дохуя? У тебя в рельсах никогда не было несколько сотен миграций? Тебе нравится пялиться в schema.rb? У тебя, наверное, и коллег нет, или все они с большой любовью делают то же самое?
Техническая возмножность то, что ты хочешь делать есть, но это нихуя не удобно в большинстве случаев, и создает охуенно большое пространство для проблем.
>>42850
Нет, я так не говорю, это твоя фантазия.
No offence, bro, но ты выступаешь сейчас с позиции быдлокодера.
В моём текущем проекте например CI не пропустит билд если закоммитишь файл с <80% покрытием тестами.
Откуда ты знаешь что я хочу? Я нигде не говорил чего хочу.
В данном конкретном случае поместить пересчет счетчика в триггер/хранимку - вполне неплохая идея. Например, если приложение - месенджер с чат-комнатами, сообщения пишут часто, надо постоянно обновлять счетчик количества сообщений в комнате. Это действие вероятно станет ботлнеком при достижении определенного объема данных. Хранимка/триггер будет намного эффективней по перформансу. Не так удобна для поддержки, но у каждого решения свои плюсы и минусы, которые хорошо бы знать и уметь использовать когда нужно.
>Ты так говоришь, как будто бы это что-то плохое
Нет, я так не говорю, это твоя фантазия.
>Стартапер дохуя? У тебя в рельсах никогда не было несколько сотен миграций? Тебе нравится пялиться в schema.rb? У тебя, наверное, и коллег нет, или все они с большой любовью делают то же самое?
No offence, bro, но ты выступаешь сейчас с позиции быдлокодера.
В моём текущем проекте например CI не пропустит билд если закоммитишь файл с <80% покрытием тестами.
>Техническая возмножность то, что ты хочешь делать есть, но это нихуя не удобно в большинстве случаев, и создает охуенно большое пространство для проблем.
Откуда ты знаешь что я хочу? Я нигде не говорил чего хочу.
В данном конкретном случае поместить пересчет счетчика в триггер/хранимку - вполне неплохая идея. Например, если приложение - месенджер с чат-комнатами, сообщения пишут часто, надо постоянно обновлять счетчик количества сообщений в комнате. Это действие вероятно станет ботлнеком при достижении определенного объема данных. Хранимка/триггер будет намного эффективней по перформансу. Не так удобна для поддержки, но у каждого решения свои плюсы и минусы, которые хорошо бы знать и уметь использовать когда нужно.
>>42850
https://github.com/jalkoby/squasher
>У тебя в рельсах никогда не было несколько сотен миграций?
https://github.com/jalkoby/squasher
>>42852
Это не бизнес логика. Ты предлагаешь её хранить в триггерах и процедурках налево и направо. Я выше писал, что если ты так делаешь, могут возникнуть проблемы. Необходима хорошая документация.
То есть ты высказываешь ту же самую мысль, что я описал ранее, но делаешь это специально настолько ублюдочно, чтобы развести срач.
>>42856
Интересно, но есть подозрение, что он не будет корректно работать с последовательностью миграций, которые апдейтят связанные между собой хранимки.
>Откуда ты знаешь что я хочу? Я нигде не говорил чего хочу.
>В данном конкретном случае поместить пересчет счетчика в триггер/хранимку - вполне неплохая идея
Это не бизнес логика. Ты предлагаешь её хранить в триггерах и процедурках налево и направо. Я выше писал, что если ты так делаешь, могут возникнуть проблемы. Необходима хорошая документация.
>Не так удобна для поддержки, но у каждого решения свои плюсы и минусы, которые хорошо бы знать и уметь использовать когда нужно.
То есть ты высказываешь ту же самую мысль, что я описал ранее, но делаешь это специально настолько ублюдочно, чтобы развести срач.
>>42856
Интересно, но есть подозрение, что он не будет корректно работать с последовательностью миграций, которые апдейтят связанные между собой хранимки.
>>44638
Ты добавил поведение методу save, которое от него не ожидается. Он должен сохранять объект, а не устанавливать какие-либо значения для него. Пользователи твоего класса ожидают, что save будет работать как обычно.
Ты добавил поведение методу save, которое от него не ожидается. Он должен сохранять объект, а не устанавливать какие-либо значения для него. Пользователи твоего класса ожидают, что save будет работать как обычно.
22 Кб, 305x229>>45012
О боже, какой кошмар, бедные пользователи моего класса, я обманул их ожидания.
Нужно срочно запретить оверрайдинг методов при наследовании чтобы не обманывать ожидания пользователей. Сообщите в комитет по ООП, они должны знать!!!!
О боже, какой кошмар, бедные пользователи моего класса, я обманул их ожидания.
Нужно срочно запретить оверрайдинг методов при наследовании чтобы не обманывать ожидания пользователей. Сообщите в комитет по ООП, они должны знать!!!!
>>45023
Почему, что он тебе сделал?
Почему, что он тебе сделал?
>>45086
Чувак, ты какой-то странный, тебе вполне верное замечание сделали. Это важно, чтобы методы делали то, что описано в их сигнатуре. Это признак хорошего, понятного кода. Твой код пахнет так себе.
Чувак, ты какой-то странный, тебе вполне верное замечание сделали. Это важно, чтобы методы делали то, что описано в их сигнатуре. Это признак хорошего, понятного кода. Твой код пахнет так себе.
>>45501
То есть метод save не должен проводить валидацию, не должен обновлять timestamps, не должен вызывать before_ и after_ колбэки, обновлять changed_attributes, т.к. это всё не упомянуто в сигнатуре? Тогда рельсы пахнут еще в 1000 раз хуже.
То есть метод save не должен проводить валидацию, не должен обновлять timestamps, не должен вызывать before_ и after_ колбэки, обновлять changed_attributes, т.к. это всё не упомянуто в сигнатуре? Тогда рельсы пахнут еще в 1000 раз хуже.
Да и в целом перегрузку методов при наследовании надо убрать из ООП, верно?
Про валидацию вообще не понимаю как ты может засунуть не валидные данные?Я думаю что бы сделать save у модели даннвх данные нуэно проверить вне где то
>>45682
Долбоёб, не повторять надо, а осмысленные фразы выдавать.
Долбоёб, не повторять надо, а осмысленные фразы выдавать.
Существует ли похожий язык, только нацеленный не на веб, а приложения? Хотелось бы начать с чего то программирование, но на С++ чет не хочется.
>>46183
Очевидный питон очевиден. Пример декстопного приложения на питоне: https://github.com/GNOME/meld
Но он тоже интерпретируемый, и чего-то требуещего производительности не сделаешь.
Менее похожий, но всё же что-то как-то - это Scala под JVM.
Для мобильных приложений бери Dart/Flutter, лучше ничего нету.
Очевидный питон очевиден. Пример декстопного приложения на питоне: https://github.com/GNOME/meld
Но он тоже интерпретируемый, и чего-то требуещего производительности не сделаешь.
Менее похожий, но всё же что-то как-то - это Scala под JVM.
Для мобильных приложений бери Dart/Flutter, лучше ничего нету.
>>46183
Но если тебе просто для вката в программирование, то на руби во время обучения пили консольные приложения, а там до рельсов рукой подать.
Для построения нескучного UI в консольных приложениях есть гем https://piotrmurach.github.io/tty/
Но если тебе просто для вката в программирование, то на руби во время обучения пили консольные приложения, а там до рельсов рукой подать.
Для построения нескучного UI в консольных приложениях есть гем https://piotrmurach.github.io/tty/
>>24437 (OP)
Господа, подскажите, пожалуйста, где можно найти полное описание синтаксиса Руби без ёбаных гайдов для новичков?
А то не очень понятно как читать подобное: huipizda :ebat => kopat, pizdec {:nahui => hiv}
Господа, подскажите, пожалуйста, где можно найти полное описание синтаксиса Руби без ёбаных гайдов для новичков?
А то не очень понятно как читать подобное: huipizda :ebat => kopat, pizdec {:nahui => hiv}
Вангую что вопрос у меня глупый, но никак не могу понять как сделать в рельсах следующее..
Есть модель tour с полями tour_id и title + соответствующий контроллер со стандартными методами index, show и т.п.
Есть контроллер stats со стандартными методами index, show и т.п.
В routes.rb:
resources :tours do
resources :statistics
end
Т.о., валидны урл-ы типа /tours/1/statistics.
Ппонимаю, что выглядит криво, но вопрос не в этом.
На страницах по адресу типа /tours/1/statistics мне нужно вывести форму с выпадающим селектом этих tours по id, причем по нажатию submit с выбранным tour_id, скажем, 2, браузер должен переадресоваться на /tours/2/statistics.
Пишу такую форму:
<%= form_with model: @tour do |f| %>
<%= f.select(:tour_id, Tour.all.collect {|u| [u.title, u.id]}, :prompt => 'Select') %>
<%= f.submit("Submit") %>
<% end %>
Ожидаемо переадресует на /tours/2. Не могу понять, что мне надо сделать для нужного мне результата. Или вообще перепилить statistics из отдельного контроллера в метод контроллера tour? Но и тогда не понимаю как сделать и, главное, где копать.
Есть модель tour с полями tour_id и title + соответствующий контроллер со стандартными методами index, show и т.п.
Есть контроллер stats со стандартными методами index, show и т.п.
В routes.rb:
resources :tours do
resources :statistics
end
Т.о., валидны урл-ы типа /tours/1/statistics.
Ппонимаю, что выглядит криво, но вопрос не в этом.
На страницах по адресу типа /tours/1/statistics мне нужно вывести форму с выпадающим селектом этих tours по id, причем по нажатию submit с выбранным tour_id, скажем, 2, браузер должен переадресоваться на /tours/2/statistics.
Пишу такую форму:
<%= form_with model: @tour do |f| %>
<%= f.select(:tour_id, Tour.all.collect {|u| [u.title, u.id]}, :prompt => 'Select') %>
<%= f.submit("Submit") %>
<% end %>
Ожидаемо переадресует на /tours/2. Не могу понять, что мне надо сделать для нужного мне результата. Или вообще перепилить statistics из отдельного контроллера в метод контроллера tour? Но и тогда не понимаю как сделать и, главное, где копать.
>>48813
А форму не хочешь через simple_form сделать? Селект особенно твой, очень страшно такое видеть.
Если я правильно понял твой вопрос, то ты должен в контроллере в методе :update или :save или что у тебя там, вот ты должен в конце метода сделать redirect_to на стату, там разберешься.
А форму не хочешь через simple_form сделать? Селект особенно твой, очень страшно такое видеть.
Если я правильно понял твой вопрос, то ты должен в контроллере в методе :update или :save или что у тебя там, вот ты должен в конце метода сделать redirect_to на стату, там разберешься.
>>49075
О, спасибо, совсем забыл про этот гем. Мало работал с этой темой.
Ну из официальных api доков взял, как-то так.
Ага, были такие мысли, попробую.
>А форму не хочешь через simple_form сделать?
О, спасибо, совсем забыл про этот гем. Мало работал с этой темой.
>Селект особенно твой, очень страшно такое видеть.
Ну из официальных api доков взял, как-то так.
>Если я правильно понял твой вопрос, то ты должен в контроллере в методе :update или :save или что у тебя там, вот ты должен в конце метода сделать redirect_to на стату, там разберешься.
Ага, были такие мысли, попробую.
>>48813
Осиль уже react или vue. Это не троллинг, если что, я за последние года 3, а то и больше, не могу вспомнить что бы мне хоть раз пришлось рельсами что-то кроме json или xml отдавать.
>2k19
>Рендерить html на сервере
Осиль уже react или vue. Это не троллинг, если что, я за последние года 3, а то и больше, не могу вспомнить что бы мне хоть раз пришлось рельсами что-то кроме json или xml отдавать.
>>49167
Да, это в планах.
Вопрос в том, по каким критериям стоит делать выбор. На данный момент vue, react, angular и тд, и тп для меня темный лес.
Да, это в планах.
Вопрос в том, по каким критериям стоит делать выбор. На данный момент vue, react, angular и тд, и тп для меня темный лес.
>>48813
Не понятно, что ты хочешь сделать и ты видимо сам толком не понимаешь, отсюда и проблема.
Предположу что есть какая-то страница статы с быстрой goto-формой.
Есть три способа:
1. Делаем стату отдельным контроллером, а форма просто будет сабмитить id тура на StatsController#show.
2. Делаем стату collection-action-методом, а форма просто будет сабмитить id тура на ToursController#stats.
3. Делаем так как ты сказал, но обрабатываем сабмит js-ом, подставляя в window.location = '/tours/:id/stats'. И тащемта опять же тут не нужен отдельный контроллер, можно обойтись member-action-методом ToursController#stats.
>>49075
Не слушай школьника. И никогда не используй говно-гемы для форм. Сейчас у тебя отличная форма.
Только сделай f.select(:tour_id, Tour.limit(100).pluck(:title, :id), :prompt => 'Select')
Не понятно, что ты хочешь сделать и ты видимо сам толком не понимаешь, отсюда и проблема.
Предположу что есть какая-то страница статы с быстрой goto-формой.
Есть три способа:
1. Делаем стату отдельным контроллером, а форма просто будет сабмитить id тура на StatsController#show.
2. Делаем стату collection-action-методом, а форма просто будет сабмитить id тура на ToursController#stats.
3. Делаем так как ты сказал, но обрабатываем сабмит js-ом, подставляя в window.location = '/tours/:id/stats'. И тащемта опять же тут не нужен отдельный контроллер, можно обойтись member-action-методом ToursController#stats.
>>49075
Не слушай школьника. И никогда не используй говно-гемы для форм. Сейчас у тебя отличная форма.
Только сделай f.select(:tour_id, Tour.limit(100).pluck(:title, :id), :prompt => 'Select')
>>49212
Да, так и есть.
Все получилось с добавлением редиректа в контроллер + добавил в форму method: :get и local: true.
Вообще, понял что в любом случае вариант с js будет более гибким, т.ч. пойду изучать как правильно его связывать с рельсами. Всем спс.
>Предположу что есть какая-то страница статы с быстрой goto-формой.
Да, так и есть.
Все получилось с добавлением редиректа в контроллер + добавил в форму method: :get и local: true.
Вообще, понял что в любом случае вариант с js будет более гибким, т.ч. пойду изучать как правильно его связывать с рельсами. Всем спс.
>>49420
Лол
Это что-то на уровне подпилить ножки у стола, чтобы отрегулировать высоту стула.
>Все получилось с добавлением редиректа в контроллер
Лол
Это что-то на уровне подпилить ножки у стола, чтобы отрегулировать высоту стула.
1,6 Мб, 4032x3024>>49167
Нинужное говноедство на которое убивается немеряно времени, а профита против turbolinks + rjs - чуть более чем нихуя.
Почитать на тему: https://medium.com/@jmanrubia/escaping-the-spa-rabbit-hole-with-turbolinks-903f942bf52c
>>49212
Вызов модели из вью - мы вам перезвоним.
>>49708
Двачую.
А делать надо было вот что. Для этой странички написать ЖС, в нём навесить обработчик onChange для селекта, который будет менять form action на "/tours/" + select.value +"/statistics". Всё.
Если пойти чуть дальше, то этот же обработчик может заодно и сабмитить форму, тогда можно убрать нинужную кнопку. Да и форму можно убрать, и делать переход с помощью window.location. Самое простое = самое лучшее.
> react или vue
Нинужное говноедство на которое убивается немеряно времени, а профита против turbolinks + rjs - чуть более чем нихуя.
Почитать на тему: https://medium.com/@jmanrubia/escaping-the-spa-rabbit-hole-with-turbolinks-903f942bf52c
>>49212
>Только сделай f.select(:tour_id, Tour.limit(100).pluck(:title, :id), :prompt => 'Select')
Вызов модели из вью - мы вам перезвоним.
>>49708
Двачую.
А делать надо было вот что. Для этой странички написать ЖС, в нём навесить обработчик onChange для селекта, который будет менять form action на "/tours/" + select.value +"/statistics". Всё.
Если пойти чуть дальше, то этот же обработчик может заодно и сабмитить форму, тогда можно убрать нинужную кнопку. Да и форму можно убрать, и делать переход с помощью window.location. Самое простое = самое лучшее.
Алсо, каким надо быть уёбком, чтобы человеку, которому нужон однострочник на JS, советовать выучить react.
>>49946
Скажу честно, статью не читал, слишком длинная. Если ты тратишь с vue больше времени, чем с rjs, то ты что-то делаешь не так или у тебя просто еще недостаточно опыта работы с ним. Я разрабатывал всякие сложные формочки и прочие сильно интерактивные штуки еще во времена тотального доминирования jquery и помню как даже первый angular был просто божественным откровением. Наконец-то не надо было вешать десятки обработчиков всяких onclick и onchange и 100% обосраться в процессе в каком-нибудь селекторе, или забыть обновить доступные значения в селекте, или забыть скрыть часть полей, или еще миллион других вариантов оставить интерфейс в неправильном виде удачи все это сделать с помощью rjs, кстати. С ангуляром (а сейчас с react/vue) можно было просто менять стейт в js и он сам правильно отображался на интерфейс. Это реально был переход от императивного к декларативному программированию на фронтенде.
>>49991
В данном случае это, конечно, оверкилл, но это учебный проект и в них оверкиллы это норма и даже необходимость. В будущем, когда ему понадобится сделать и правда что-то сложное на фронтенде, он уже будет знаком с подходящими для этого инструментами.
>Нинужное говноедство на которое убивается немеряно времени, а профита против turbolinks + rjs - чуть более чем нихуя.
Скажу честно, статью не читал, слишком длинная. Если ты тратишь с vue больше времени, чем с rjs, то ты что-то делаешь не так или у тебя просто еще недостаточно опыта работы с ним. Я разрабатывал всякие сложные формочки и прочие сильно интерактивные штуки еще во времена тотального доминирования jquery и помню как даже первый angular был просто божественным откровением. Наконец-то не надо было вешать десятки обработчиков всяких onclick и onchange и 100% обосраться в процессе в каком-нибудь селекторе, или забыть обновить доступные значения в селекте, или забыть скрыть часть полей, или еще миллион других вариантов оставить интерфейс в неправильном виде удачи все это сделать с помощью rjs, кстати. С ангуляром (а сейчас с react/vue) можно было просто менять стейт в js и он сам правильно отображался на интерфейс. Это реально был переход от императивного к декларативному программированию на фронтенде.
>>49991
В данном случае это, конечно, оверкилл, но это учебный проект и в них оверкиллы это норма и даже необходимость. В будущем, когда ему понадобится сделать и правда что-то сложное на фронтенде, он уже будет знаком с подходящими для этого инструментами.
>>49946
Сложно переть со своим мнением против догм, но это самое адекватное решение в 99% случаев.
Конечно, вызов вызову рознь, если там сложные квери, то разумеется нельзя. Но в данном случае это ок.
Если бы мне соискатель сказал, что тут нужно завернуть в декоратор, налепить view-model и прочей поеботы и настаивал бы на этом после уточняющих вопросов, то я бы такому "правильному" точно перезвонил.
>Вызов модели из вью - мы вам перезвоним.
Сложно переть со своим мнением против догм, но это самое адекватное решение в 99% случаев.
Конечно, вызов вызову рознь, если там сложные квери, то разумеется нельзя. Но в данном случае это ок.
Если бы мне соискатель сказал, что тут нужно завернуть в декоратор, налепить view-model и прочей поеботы и настаивал бы на этом после уточняющих вопросов, то я бы такому "правильному" точно перезвонил.
>>50130
Тебе достаточно определить переменную в экшене, пёс.
>Если бы мне соискатель сказал, что тут нужно завернуть в декоратор, налепить view-model и прочей поеботы и настаивал бы на этом после уточняющих вопросов, то я бы такому "правильному" точно перезвонил.
Тебе достаточно определить переменную в экшене, пёс.
а зачем он нужон ваш руби? что на нём писать то и в какой сфере?
чё-то в последнее время так наслуху он, но судя по всему предполгаю, что это очередной язык который "может всё", но при этом для неосиляторов.
чё-то в последнее время так наслуху он, но судя по всему предполгаю, что это очередной язык который "может всё", но при этом для неосиляторов.
>>50212
Руби нужон для написания блогов за 15 минут. Для остального он нинужен.
Алсо, если у тебя руби на слуху, то ты слоупок лет на 10. Руби уже отходит в мир иной вместе с индустрией блогов за 15 минут.
Руби нужон для написания блогов за 15 минут. Для остального он нинужен.
Алсо, если у тебя руби на слуху, то ты слоупок лет на 10. Руби уже отходит в мир иной вместе с индустрией блогов за 15 минут.
>>50217
а понял это для веба какая-то хуета. ну и зачем так усиленно его дрочить? есть же универсалниые инструменты давно
html/css/js/php/mysql/c#...
а понял это для веба какая-то хуета. ну и зачем так усиленно его дрочить? есть же универсалниые инструменты давно
html/css/js/php/mysql/c#...
>>50217
алсо вас не послушаешь, так у вас всё свой век отживает. c++, php, джава что не спроси у анона всё отживает свой век. лол
алсо вас не послушаешь, так у вас всё свой век отживает. c++, php, джава что не спроси у анона всё отживает свой век. лол
>>50004
Нихуя себе оверкилл - выучить ещё один фреймворк вместо написать одну строчку. Оверкил лол.
На изучение жс-фреймворка потратишь уйму времени, а через полгода он устареет нахуй и пользы от него останется только в /пр/ глупые советы давать.
Нихуя себе оверкилл - выучить ещё один фреймворк вместо написать одну строчку. Оверкил лол.
На изучение жс-фреймворка потратишь уйму времени, а через полгода он устареет нахуй и пользы от него останется только в /пр/ глупые советы давать.
>>50854
Не понос, а шоколадный смузи. Руби - самая годнота среди неборщехлебных языков. Трюли, индид.
Не понос, а шоколадный смузи. Руби - самая годнота среди неборщехлебных языков. Трюли, индид.
>>50837
Ну это не рельсы, у react и vue публичное API сотни раз меньше. На react можно начать писать вполне вменяем код через день, на vue через пару дней. При условие, что ты уже знаком с js, конечно.
Года 3-4 назад я согласился бы. Но сейчас все устаканилось, рыночек уже года 3 как доминирует реакт и никуда уходить не собирается, плюс есть популярная альтернатива - vue и angular 1 еще часто встречается в легаси проектах. И вообще-то все, все остальное почти мертво.
>выучить ещё один фреймворк вместо написать одну строчку
Ну это не рельсы, у react и vue публичное API сотни раз меньше. На react можно начать писать вполне вменяем код через день, на vue через пару дней. При условие, что ты уже знаком с js, конечно.
>а через полгода он устареет нахуй
Года 3-4 назад я согласился бы. Но сейчас все устаканилось, рыночек уже года 3 как доминирует реакт и никуда уходить не собирается, плюс есть популярная альтернатива - vue и angular 1 еще часто встречается в легаси проектах. И вообще-то все, все остальное почти мертво.
>>50879
В эпоху хайпа рельс я вполне себе использовал руби, мой юный друг, но делал это исключительно ради денег, а не из-за каких-то его мнимых преимуществ.
В эпоху хайпа рельс я вполне себе использовал руби, мой юный друг, но делал это исключительно ради денег, а не из-за каких-то его мнимых преимуществ.
>>50884
Каков ловкач.
Каков ловкач.
>>50881
Вменяемый код который нахуй ненужон.
Вменяемый код который нахуй ненужон.
Как в руби работают с асинхронными вызовами? В интернете 2.5 статьи в отличии от того же пистона
>рыночек уже года 3 как доминирует реакт и никуда уходить не собирается, плюс есть популярная альтернатива - vue и angular 1 еще часто встречается в легаси проектах
В том и дело что популярная альтернатива появилась недавно, и так же может уйти. Появится что-то еще, и не будет спрашивать твоего мнения - уходить реакту или нет. Ангуляр третий выпустят, и будешь его с нуля учить, как учил второй после первого. Короче, у фронтендщиков уже который год каждая ночь трудная, а очко разработано так, что они без труда могут спрятать в нем десяток фреймворков.
>>50904
Уже седьмой выпустили, всем на него похуй после обосрамса с переходом с первого на второй.
Я так-то согласен, что технологии на фронте менялись слишком быстро. Но коммьюнити это тоже осознало и сейчас темп стал намного более разменянным. Как пример не только react, но webpack по-сути тоже стал дефолтом на фронте уже несколько лет как и никуда уходить не собирается, всякие react-router, redux и прочие перестали мажорные версии выпускать.
>Ангуляр третий выпустят
Уже седьмой выпустили, всем на него похуй после обосрамса с переходом с первого на второй.
Я так-то согласен, что технологии на фронте менялись слишком быстро. Но коммьюнити это тоже осознало и сейчас темп стал намного более разменянным. Как пример не только react, но webpack по-сути тоже стал дефолтом на фронте уже несколько лет как и никуда уходить не собирается, всякие react-router, redux и прочие перестали мажорные версии выпускать.
>>50906
Можно асинхронные вызовы и в одном потоке гонять
Ну это же пиздец, как у вас хайлоад писать
>GIL
Можно асинхронные вызовы и в одном потоке гонять
>Никак
Ну это же пиздец, как у вас хайлоад писать
>>50906
И питоне тоже GIL, ты путаешь aсинхронность и параллелизм. Для асинхроности в руби есть вполне годная EventMachine.
И питоне тоже GIL, ты путаешь aсинхронность и параллелизм. Для асинхроности в руби есть вполне годная EventMachine.
>>50912
Хайлоад блог за 15 минут лол кек. Как только проект на руби достигает уровня "хайлоад", его переписывают на Скалу или еще что-то другое. Таких случаев в истории единицы, их все знают наперечёт, во всех остальных случаях слово "хайлоад" используется чтобы нахмурить брови на собеседовании (обеими сторонами), и реальным хайлодом там и близко не пахло. Так что, Иван Федорович, слушайте "валенки" и не выёбывайтесь.
Хайлоад блог за 15 минут лол кек. Как только проект на руби достигает уровня "хайлоад", его переписывают на Скалу или еще что-то другое. Таких случаев в истории единицы, их все знают наперечёт, во всех остальных случаях слово "хайлоад" используется чтобы нахмурить брови на собеседовании (обеими сторонами), и реальным хайлодом там и близко не пахло. Так что, Иван Федорович, слушайте "валенки" и не выёбывайтесь.
>>50914
Да, ты прав.
Да, ты прав.
Правда ли, что вся популярность Рубина держалась на Ruby on Rails? Чем так хорош был этот фреймворк?
>>50940
Связан с беттингом, легкая интеграция и кастомизация собственной платформы для всех желающих
Связан с беттингом, легкая интеграция и кастомизация собственной платформы для всех желающих
>>50946
из за магии меньше кода по сравнению с другими фреймворками,более лаконичный код
из за магии меньше кода по сравнению с другими фреймворками,более лаконичный код
>>50947
Руби для беттинга называется Эликсир.
https://jobs.dou.ua/companies/betinvest/vacancies/55115/
Руби для беттинга называется Эликсир.
https://jobs.dou.ua/companies/betinvest/vacancies/55115/
>>51157
сиди на пистоне
сиди на пистоне
>>51163
Потому что poorly designed.
Потому что poorly designed.
>>41444
Действительно, зачем делать валидации, приведение типов, если можно во все объекты, даже небо, даже Аллаха, захуячить blank?/present? и вызывать в любом месте проекте, да, быдлокодерок?
>Ну давай рассказывай как ты каждый день борешься с present? у Object и second у Array. Я тоже, конечно, против money patching, но именно фреймворку по-моему позволительно добавить некоторые методы общего назначения в стандартную библиотеку. И как уже сказали выше некоторые из них кочуют в руби.
Действительно, зачем делать валидации, приведение типов, если можно во все объекты, даже небо, даже Аллаха, захуячить blank?/present? и вызывать в любом месте проекте, да, быдлокодерок?
>>51344
Действительно, зачем делать валидации и приведение типов, еслли можно во все обхекты захуячить blank?/present? ?
Действительно, зачем делать валидации и приведение типов, еслли можно во все обхекты захуячить blank?/present? ?
>>51512
Ты задал этот вопрос, решив подъебать собеседника, а я задал, потому что действительно хочу знать ответ. Объясни джуну, пожалуйста.
Ты задал этот вопрос, решив подъебать собеседника, а я задал, потому что действительно хочу знать ответ. Объясни джуну, пожалуйста.
>>51569
Потому что валидация и приведение данных должны быть в одном определенном месте в архитектуре приложения. Когда введёные данные прошли этот фильтр, их можно считать корректными, безопасными и оперировать ими в коде бизнес-логики.
Манки-патчинг всех в мире объектов - это фактически добавление глобальных функций. В Руби есть глобальная функция puts для вывода, но мы же строим архитектуру MVC с выводом только из View слоя. Если провести аналогию, быдлокодеры говорят - зачем нам париться с View, давайте в каждую модель хуйнём метод puts, ведь это так удобно - выводить данные модели из самой модели.
Потому что валидация и приведение данных должны быть в одном определенном месте в архитектуре приложения. Когда введёные данные прошли этот фильтр, их можно считать корректными, безопасными и оперировать ими в коде бизнес-логики.
Манки-патчинг всех в мире объектов - это фактически добавление глобальных функций. В Руби есть глобальная функция puts для вывода, но мы же строим архитектуру MVC с выводом только из View слоя. Если провести аналогию, быдлокодеры говорят - зачем нам париться с View, давайте в каждую модель хуйнём метод puts, ведь это так удобно - выводить данные модели из самой модели.
>>51827
По твоей логике у Object вообще методов быть не должно. Плюс никто не мешает present? использовать только внутри валидаторов, хотя, как по мне, он и внутри бизнес логики иногда полезен. Интересно, кстати, что ты скажешь, если завтра present? добавят в стандартную библиотеку, как уже случалось с другими методами из рельс?
И puts, кстати не глобальный метод, а метод из модуля Kernel, который замиксинен только в Object, но не в BasicObject.
По твоей логике у Object вообще методов быть не должно. Плюс никто не мешает present? использовать только внутри валидаторов, хотя, как по мне, он и внутри бизнес логики иногда полезен. Интересно, кстати, что ты скажешь, если завтра present? добавят в стандартную библиотеку, как уже случалось с другими методами из рельс?
И puts, кстати не глобальный метод, а метод из модуля Kernel, который замиксинен только в Object, но не в BasicObject.
>>51985
Никто и на похапэ не мешает писать хороший код, только почему-то на руби код в среднем по больнице лучше.
Скажу что это плохой шаг. Пока что Мац сопротивляется уже на протяжении лет так трёх. Сейчас говорю что Мац молодец, пусть вашего брата быдлокодера и дальше на хую вертит.
Никто и на похапэ не мешает писать хороший код, только почему-то на руби код в среднем по больнице лучше.
Скажу что это плохой шаг. Пока что Мац сопротивляется уже на протяжении лет так трёх. Сейчас говорю что Мац молодец, пусть вашего брата быдлокодера и дальше на хую вертит.
>>52045
И хаскел.
И хаскел.
>>51827
Я согласен по поводу валидации и обработки параметров. Но как это пересекается с present? ? Ты пишешь так, как будто бы наличие этого метода подразумевает отказ от валидаций. Сам по себе этот метод очень удобный, ничего плохого в нем нет. Проблема только в том, что это манки патчинг. Он хуевый по дефолту. Даже если в каком-то конкретном примере он приемлем, он все равно хуевый, потому что с маленького шашка начинается большая героиновая зависимость. Но ты пиздишь на present? так, как будто бы не понимаешь, в чем проблема. Тебе главное пиздеть, брюзжать, брызжать слюной.
Я согласен по поводу валидации и обработки параметров. Но как это пересекается с present? ? Ты пишешь так, как будто бы наличие этого метода подразумевает отказ от валидаций. Сам по себе этот метод очень удобный, ничего плохого в нем нет. Проблема только в том, что это манки патчинг. Он хуевый по дефолту. Даже если в каком-то конкретном примере он приемлем, он все равно хуевый, потому что с маленького шашка начинается большая героиновая зависимость. Но ты пиздишь на present? так, как будто бы не понимаешь, в чем проблема. Тебе главное пиздеть, брюзжать, брызжать слюной.
>>52074
Откуда тебе знать что для меня главное, лол. Я даю аргументецию, а ты на личности переходишь. Неудивительно что такому быдлу нужен глобальный манки-патчинг лоол.
Откуда тебе знать что для меня главное, лол. Я даю аргументецию, а ты на личности переходишь. Неудивительно что такому быдлу нужен глобальный манки-патчинг лоол.
>>52102
Тем временем ниодного конкретного примера чем же present? так плохо, кроме кококо-манкипатчинг так и не было.
Тем временем ниодного конкретного примера чем же present? так плохо, кроме кококо-манкипатчинг так и не было.
>>52102
Твои аргументы инвалидны. Ты ничего не говоришь конкретно о present?, ты подменяешь понятия и предполагаешь, что адепты present? в остальном тоже говнокодеры.
Твои аргументы инвалидны. Ты ничего не говоришь конкретно о present?, ты подменяешь понятия и предполагаешь, что адепты present? в остальном тоже говнокодеры.
>>52128
Тут несколько человек с тобой разговаривают. Я хочу разобраться. Объясни. Ты не объясняешь нихуя. Я настроен на конструктивный диалог.
Тут несколько человек с тобой разговаривают. Я хочу разобраться. Объясни. Ты не объясняешь нихуя. Я настроен на конструктивный диалог.
>>52138
Джуну который задавал вопрос я достаточно подробно ответил. Если тебе после этого что-то непонятно, то тебе потребуется поставить вопрос чтобы получить на него ответ. "Объясни. Ты не объясняешь нихуя." - как ты живешь с такими коммуникационными навыками.
Джуну который задавал вопрос я достаточно подробно ответил. Если тебе после этого что-то непонятно, то тебе потребуется поставить вопрос чтобы получить на него ответ. "Объясни. Ты не объясняешь нихуя." - как ты живешь с такими коммуникационными навыками.
>>52142
Я не он, но мне тоже интересно, чем плох present? и я, например, не понял как связаны объекты для валидации входящих данных и этот метод. То есть я понимаю, конечно, что его можно использовать как замену очень простой валидации и это, наверное, не очень хорошо, но ведь это не единственный юзкейс, да и внутри самих валидаторов скажем почему бы его не использовать.
Пример, есть очень ебанутое API, которое для одного из ключей в json объекте может возвращать null, пустую строку или массив - пустой или со строками. У меня есть класс, который приводит всю эту хуйню к нормально виду и в нем есть примерно вот такая строка: object[:foo] = [] unless object[:foo].present?
Что в ней плохого, если представить, что я до этого уже провалидировал, что от API пришел один из 3 вариантов выше?
Я не он, но мне тоже интересно, чем плох present? и я, например, не понял как связаны объекты для валидации входящих данных и этот метод. То есть я понимаю, конечно, что его можно использовать как замену очень простой валидации и это, наверное, не очень хорошо, но ведь это не единственный юзкейс, да и внутри самих валидаторов скажем почему бы его не использовать.
Пример, есть очень ебанутое API, которое для одного из ключей в json объекте может возвращать null, пустую строку или массив - пустой или со строками. У меня есть класс, который приводит всю эту хуйню к нормально виду и в нем есть примерно вот такая строка: object[:foo] = [] unless object[:foo].present?
Что в ней плохого, если представить, что я до этого уже провалидировал, что от API пришел один из 3 вариантов выше?
42 Кб, 386x269>>52248
Я написал чем плох манки-патчинг всех в мире объектов и почему это не надо делать на уровне языка. Ты спрашиваешь чем плох вызов метода в конкретном месте конкретного проекта.
Я написал чем плох манки-патчинг всех в мире объектов и почему это не надо делать на уровне языка. Ты спрашиваешь чем плох вызов метода в конкретном месте конкретного проекта.
>>52293
Нет ты противопоставлял валидации и прочие штуки методу present?
Но нигде не пояснил как одно мешает другому?
И так и не пояснил, чем плох конкретно этот манкипатчинг. А когда тебя спросили, что если добавить этот метод в стандартную библиотеку, ты просто сказал, что это плохо без аргументов.
Нет ты противопоставлял валидации и прочие штуки методу present?
>Действительно, зачем делать валидации, приведение типов, если можно во все объекты, даже небо, даже Аллаха, захуячить blank?/present?
Но нигде не пояснил как одно мешает другому?
И так и не пояснил, чем плох конкретно этот манкипатчинг. А когда тебя спросили, что если добавить этот метод в стандартную библиотеку, ты просто сказал, что это плохо без аргументов.
>Скажу что это плохой шаг. Пока что Мац сопротивляется уже на протяжении лет так трёх. Сейчас говорю что Мац молодец, пусть вашего брата быдлокодера и дальше на хую вертит.
>>52313
Я противопоставил выстраивание архитектуры манки-патчингу и глобальным функциям.
Я противопоставил выстраивание архитектуры манки-патчингу и глобальным функциям.
Какой подход лучше когда во вью нужна короткая, но всё же логика для отображения: во вью её и вписать, использовать хелпер, использовать презентер?
Сажа приклеилась зря.
Помогите не погромисту, и даже не эникею. Есть код https://pastebin.com/mU0QZ22B Нужно объяснить мне, как сделать, чтобы он работал. Установил интерпретатор, запустил файлик - не работает. Вылезает командная строка(?), исчезает - и ничего. За долю секунду разобрать, что было написано, не получается. Имеем винду и мозиллу версии 52.4.
>>56153
Нет, это от руби запах.
Нет, это от руби запах.
30/час если на пол ставки. первый месяц 20/час, так-как давно не работал. не более 4 часов в день.
50/час если на полную ставку, удаленно.
70/час на полную и в офисе, время на дорогу за их счет.
норм просить? не хочу на полную.
35 лвл. много или пофиг? куда не стоит лезть?
50/час если на полную ставку, удаленно.
70/час на полную и в офисе, время на дорогу за их счет.
норм просить? не хочу на полную.
35 лвл. много или пофиг? куда не стоит лезть?
>>56443
Ну скачай если сможешь. Там библиотек несколько и что из них заработает под виндой - вопрос. А заниматься этим вопросом никому не интересно, т.к. винда и руби мало совместимы.
А это скрипт для чего, как ты думаешь?
Ну скачай если сможешь. Там библиотек несколько и что из них заработает под виндой - вопрос. А заниматься этим вопросом никому не интересно, т.к. винда и руби мало совместимы.
>Што?
А это скрипт для чего, как ты думаешь?
>>56446
А разве по типу ошибки неясно, какую именно, нужно наугад библиотеки перебирать и тестить? Не подскажешь, где качать эти библиотеки? Или все равно работать не будет?
Взрослые одетые тины - ну такое себе цопе.
>>56448
Я не хакир. И ради одного скрипта учиться пользоваться линуксом - это фантастика.
>Там библиотек несколько и что из них заработает под виндой - вопрос.
А разве по типу ошибки неясно, какую именно, нужно наугад библиотеки перебирать и тестить? Не подскажешь, где качать эти библиотеки? Или все равно работать не будет?
>А это скрипт для чего, как ты думаешь?
Взрослые одетые тины - ну такое себе цопе.
>>56448
Я не хакир. И ради одного скрипта учиться пользоваться линуксом - это фантастика.
>>56450
Библиотеки
Как это в винде устанавливать не представляю.
Библиотеки
>require 'excon'
>require 'fileutils'
>require 'nokogiri'
>require 'open-uri'
>require 'rmagick'
>require 'ruby-progressbar'
Как это в винде устанавливать не представляю.
>>56458
Ок, спасибо.
Ок, спасибо.
С rmagick могут быть трудности, с остальным должно быть проще.
https://www.google.com.ua/search?q=install+ruby+gems+on+windows
https://www.google.com.ua/search?q=install+ruby+gems+on+windows
Помню как я пытался ImageMagick на винде заставить работать в руби, ух бля, не завидую тебе.
>>56480
Но это ж оверкилл когда для пары методов новый класс создавать когда можно хелпер заюзать, не?
Но это ж оверкилл когда для пары методов новый класс создавать когда можно хелпер заюзать, не?
>>56488
Практически всегда наступает такой момент, когда логика расширяется, и какой-то умник продолжает её пихать в хелперы. Лучше сразу делать нормально. Это как урна мимо которой всегда бросают.
Практически всегда наступает такой момент, когда логика расширяется, и какой-то умник продолжает её пихать в хелперы. Лучше сразу делать нормально. Это как урна мимо которой всегда бросают.
>>56488
В хелперах похерен ООП. Максимум пару методов там оставляй.
В хелперах похерен ООП. Максимум пару методов там оставляй.
Подскажите идею для пет проекта.Что бы на уровень мидл тянуло. Кроме магаза в голову ни чего не приходит
383 Кб, 512x512>>58248
Имиджборда, чтобы выдавала по крайней мере 5 тысяч запросов в секунду.
Имиджборда, чтобы выдавала по крайней мере 5 тысяч запросов в секунду.
>>58308
Ну, проект "для себя"
Ну, проект "для себя"
>>58556
Мань не делай хуйню. Придумай что-то интереснее и сложнее, сделай систему краша вк-групп с циклическим добавлением друг дружки ботов.
Это понял 100-200 аккаунтов, и они по кругу бы постоянно добавляли друг друга в групповой чат ВКонтакте и удалялись оттуда, создавая с этим бешеный флуд, и невозможность их кикнуть/забанить, ну только если через API как-то и всех сразу, но они бы инвайтили обратно того кого кикнул овнер.
Так-бы
Мань не делай хуйню. Придумай что-то интереснее и сложнее, сделай систему краша вк-групп с циклическим добавлением друг дружки ботов.
Это понял 100-200 аккаунтов, и они по кругу бы постоянно добавляли друг друга в групповой чат ВКонтакте и удалялись оттуда, создавая с этим бешеный флуд, и невозможность их кикнуть/забанить, ну только если через API как-то и всех сразу, но они бы инвайтили обратно того кого кикнул овнер.
Так-бы
>>58825
так бы... закрашить можно было кучу конференций ВКонтакте и было бы весело, я бы проспонсировал 200+ ВК акков хули поржать можно
так бы... закрашить можно было кучу конференций ВКонтакте и было бы весело, я бы проспонсировал 200+ ВК акков хули поржать можно
>>58825
охуенно
охуенно
>>24437 (OP)
Объясните, рубисты.
Сам хотел подергать необычные языки, чтобы быть более грамотным, открыть что-то новое...
>Ну короче все языки были хуйней я хотел запилить че-нить для человека, простое, гибкое...
>гуглишь туторы про работку я массивами
>так короче 100500 ненужных прикрученных способов есть
>где тут индексация так такс
>ну короче ВАМ ИНДЕКСАЦИЯ НЕЧАСТО БУДЕТ НУЖНА поэтому ее тут и нет ХАХАХАХХАХА
>..
>втф??
Объясните, рубисты.
Сам хотел подергать необычные языки, чтобы быть более грамотным, открыть что-то новое...
>>60305
Научись нормально выражать свои мысли. Не понятно, о чем ты вообще пишешь и что тебе надо.
Научись нормально выражать свои мысли. Не понятно, о чем ты вообще пишешь и что тебе надо.
>>60321
Что тебе не понятно? Как работать с массивами? Оперировать значениями?
ПС я знаю уже пару способов и все они мне не нравятся
Что тебе не понятно? Как работать с массивами? Оперировать значениями?
ПС я знаю уже пару способов и все они мне не нравятся
>>60325
Например?
Индексы есть
>ПС я знаю уже пару способов и все они мне не нравятся
Например?
>ну короче ВАМ ИНДЕКСАЦИЯ НЕЧАСТО БУДЕТ НУЖНА поэтому ее тут и нет ХАХАХАХХАХА
Индексы есть
>>60335
Покеж. массив[х]=2 или массив[да]=нет или массив[длина/2]=массив[длина], ну и добавить(добавляемое, массив), до кучи.
Например через step, только я не знаю новомодный ли он, или старый.
>индекасы есть
Покеж. массив[х]=2 или массив[да]=нет или массив[длина/2]=массив[длина], ну и добавить(добавляемое, массив), до кучи.
>например
Например через step, только я не знаю новомодный ли он, или старый.
76 Кб, 600x399>>60342
так есть же array[0] = "value"
КАВО?
НЕПОНЕЛ
array.push(value)
>массив[х]=2
так есть же array[0] = "value"
>массив[да]=нет
КАВО?
>массив[длина/2]=массив[длина]
НЕПОНЕЛ
>добавить(добавляемое, массив)
array.push(value)
>>60342
ПХПшник что ли?
Я, кстати, тоже с трудом понял, что ты понаписал.
мимодругойрубист
>массив[да]=нет
ПХПшник что ли?
Я, кстати, тоже с трудом понял, что ты понаписал.
мимодругойрубист
>>60360
В руби массив это традиционный массив и у него могут быть только цифровые индексы. Если тебе нужен ассоциативный массив, то он называется Hash.
https://devdocs.io/ruby~2.5/array
https://devdocs.io/ruby~2.5/enumerable
Просвещайся.
В руби массив это традиционный массив и у него могут быть только цифровые индексы. Если тебе нужен ассоциативный массив, то он называется Hash.
>А как удалить элемент из массива из любого индекса?
https://devdocs.io/ruby~2.5/array
https://devdocs.io/ruby~2.5/enumerable
Просвещайся.
>>60361
>>60362
Сяяяп, ладно, пойду почекаю. Вероятно, я в прошлое наше с руби знакомство затупил и у меня просто глаза разбежались от странностей.
Как вам сам язык-то? Че-нить прикольное(серьезное) с ним делаете?
>>60364
>>60362
Сяяяп, ладно, пойду почекаю. Вероятно, я в прошлое наше с руби знакомство затупил и у меня просто глаза разбежались от странностей.
Как вам сам язык-то? Че-нить прикольное(серьезное) с ним делаете?
>>60364
>я делаль язык прежде всего для людей
>и што што тормозит, для людей ЖЕ
>пока компилируется можете сходить поссать, или кофе там выпить, круто же! для людей11!!
>>60358
Да, нормально. В большистве статически типизированных язык все типы по-дефолту nullable, что по-сути тоже их делает довольно динамически типизированными и ничего пишут же люди.
>Помню начал чекать руби, но ненавижу динамикодрисню
>Помню начал чекать еблю в жопу, но ненавижу пидоров
>Как вы можете на ней так писать?
Да, нормально. В большистве статически типизированных язык все типы по-дефолту nullable, что по-сути тоже их делает довольно динамически типизированными и ничего пишут же люди.
>>60366
Ничего особенного. Пишу в меру хуйлоадный проект, плюс на беке куча ебанутой бизнес логики покрытой десятками тысяч тестов. Вообще подход очень неторопливый и интерпрайзный ко всему, я даже удивлен почему когда-то давно взяли руби, а не какую-нибудь джаву.
>Че-нить прикольное(серьезное) с ним делаете?
Ничего особенного. Пишу в меру хуйлоадный проект, плюс на беке куча ебанутой бизнес логики покрытой десятками тысяч тестов. Вообще подход очень неторопливый и интерпрайзный ко всему, я даже удивлен почему когда-то давно взяли руби, а не какую-нибудь джаву.
>>60370
Ну рассказывай для чего тебе скорости руби не хватает. А то видел я таких, у них запрос к базе по полминуты делается, а виноват руби.
Ну рассказывай для чего тебе скорости руби не хватает. А то видел я таких, у них запрос к базе по полминуты делается, а виноват руби.
Помогите ньюфагу. Почему если я размещаю метод edit (редактирование статьи в моём случае) ниже create (создание статьи), то браузер пишет, что значение переменной равно нулю? А если выше, то всё нормально.
>>61645
Может
Может
>>61631
Сори анон, скинул работающий код. Совсем кукушка поехала.
Сори анон, скинул работающий код. Совсем кукушка поехала.
https://github.com/ruby-association/prep-test/blob/master/silver.md
https://github.com/ruby-association/prep-test/blob/master/gold.md
Братишки, я вам тестов прямо от Матца покушать принес. Голдовый на удивление достаточно хардкорный.
https://github.com/ruby-association/prep-test/blob/master/gold.md
Братишки, я вам тестов прямо от Матца покушать принес. Голдовый на удивление достаточно хардкорный.
Есть ли тут аноны, которые делали что-нибудь с е-коммерсом?
Если коротко, то поясните разницу между: Cart (aka Basket) vs Order vs Invoice vs Payment [vs Checkout]. инбифо, я конечно же понимаю, что это значит, но с точки зрения сущностей мне не понятно, что нужно, а что нет
Я короче не знаю, как правильно смоделировать покупки.
Во-первых, корзина. С одной стороны самостоятельная штука, а с другой это один-в-один таблица заказов. Но при этом корзины могут все-таки забросить и негоже им лежать вместе с заказами. Хотя какая хуй разница.
Во-вторых, что за сущность такая инвойс. Я ее ни в юридическом смысле не понимаю, ни в техническом. Судя по всем это выражение факта оплаты, несмотря на то что инвойсы вроде как выставляют НА оплату.
Чекаут это видимо тоже суть есть оплата.
Посмотрел немного как сделано в Spree. Там походу только две сущности - Order (он же корзина в статусе "cart") и Payment.
Короче, кто работал с этой предметной областью, подскажите, какие сущности нужно выделять. И как все-таки быть с корзиной.
---
Еще вопрос по поводу Spree. Насколько это серьезный движок, в плане архитектуры, масштабируемости и оптимизированности? Стоит ли подглядывать их практики и решения или даже использовать его или это сорт оф Redmine - хорошая, но тяжелая коробка, в которую лучше не лезть.
Если коротко, то поясните разницу между: Cart (aka Basket) vs Order vs Invoice vs Payment [vs Checkout]. инбифо, я конечно же понимаю, что это значит, но с точки зрения сущностей мне не понятно, что нужно, а что нет
Я короче не знаю, как правильно смоделировать покупки.
Во-первых, корзина. С одной стороны самостоятельная штука, а с другой это один-в-один таблица заказов. Но при этом корзины могут все-таки забросить и негоже им лежать вместе с заказами. Хотя какая хуй разница.
Во-вторых, что за сущность такая инвойс. Я ее ни в юридическом смысле не понимаю, ни в техническом. Судя по всем это выражение факта оплаты, несмотря на то что инвойсы вроде как выставляют НА оплату.
Чекаут это видимо тоже суть есть оплата.
Посмотрел немного как сделано в Spree. Там походу только две сущности - Order (он же корзина в статусе "cart") и Payment.
Короче, кто работал с этой предметной областью, подскажите, какие сущности нужно выделять. И как все-таки быть с корзиной.
---
Еще вопрос по поводу Spree. Насколько это серьезный движок, в плане архитектуры, масштабируемости и оптимизированности? Стоит ли подглядывать их практики и решения или даже использовать его или это сорт оф Redmine - хорошая, но тяжелая коробка, в которую лучше не лезть.
Поясните за колбеки у моделей в Rails. Почему в интернетах пишут что это говно? По-моему очень удобно если например среди полей, которые ты апдейтишь в модели есть определенное поле с определенным значением (status=published например), то можно в колбеке это обработать и сделать какие-то сопутствующие действия, например записать каррент юзера в поле publisher_id.
>>64513
Cart и Order разделяй. В корзине у тебя только товары. В заказе еще и данные покупателя/доставки/оплаты/аллаха.
Не забудь, что товары в корзине - это отдельная сущность (i.e. Line Item), т.к. если в ассортименте на сайте, например, поменяются цены, то в корзине/заказе все должно оставаться так же, как и на момент доавления в корзину/оформления заказа.
Все остальной из другой оперы и тебе особенно не надо.
По Spree смотрел довольно давно, вроде хорошо задокументированно все, но я предпочитаю самопис, т.к. у текущего проекта по ИМ очень специфичная бизнес-логика.
Пользуясь случаем спрошу у местных - готовим перекат на самопис на рельсах с Opencart.
Как по уму настроить 301 переадресацию со старых опенкартовских урлов вида "<domain.ru>/index.php?route=product/search&search=123" на, к примеру, "<domain.ru>/products?search=123" штатными средствами? В routes.rb? Что покурить по этому поводу? Ссылочная масса в поисковиках довольно солидная, не хотелось бы терять.
Cart и Order разделяй. В корзине у тебя только товары. В заказе еще и данные покупателя/доставки/оплаты/аллаха.
Не забудь, что товары в корзине - это отдельная сущность (i.e. Line Item), т.к. если в ассортименте на сайте, например, поменяются цены, то в корзине/заказе все должно оставаться так же, как и на момент доавления в корзину/оформления заказа.
Все остальной из другой оперы и тебе особенно не надо.
По Spree смотрел довольно давно, вроде хорошо задокументированно все, но я предпочитаю самопис, т.к. у текущего проекта по ИМ очень специфичная бизнес-логика.
Пользуясь случаем спрошу у местных - готовим перекат на самопис на рельсах с Opencart.
Как по уму настроить 301 переадресацию со старых опенкартовских урлов вида "<domain.ru>/index.php?route=product/search&search=123" на, к примеру, "<domain.ru>/products?search=123" штатными средствами? В routes.rb? Что покурить по этому поводу? Ссылочная масса в поисковиках довольно солидная, не хотелось бы терять.
>>64693
Можно и в routes.rb, но я бы на уровне nginx (или что вы там используете) сделал, будет быстрее работать и не придется захламлять настоящие роуты этим легаси. Если редиректить с http кодом 302, то все приличные поисковики, типа гугла, должны быстро подхватить изменения и начать выдавать новые урлы в результатах поиска.
Можно и в routes.rb, но я бы на уровне nginx (или что вы там используете) сделал, будет быстрее работать и не придется захламлять настоящие роуты этим легаси. Если редиректить с http кодом 302, то все приличные поисковики, типа гугла, должны быстро подхватить изменения и начать выдавать новые урлы в результатах поиска.
>>64786
Обосрался. 301, а не 302, конечно.
Обосрался. 301, а не 302, конечно.
>>64605
Если у тебя небольшое приложение с парой колбеков на модель, то ничего страшного в них нету. Проблемы начинаются, когда у тебя в моделях по 10+ колбеков, становится важен порядок вызова этих колбеков, эти колбеки начинают сохранять другие модели, что в свою очередь вызывает колбеки из этих моделей и это все растет как снежный ком. Один раз работал над приложением в котором сохранение поста вызывало 100+ колбеков в сумме. Ах да, еще скорость прохождения тестов тоже очень от этого страдает.
Если у тебя небольшое приложение с парой колбеков на модель, то ничего страшного в них нету. Проблемы начинаются, когда у тебя в моделях по 10+ колбеков, становится важен порядок вызова этих колбеков, эти колбеки начинают сохранять другие модели, что в свою очередь вызывает колбеки из этих моделей и это все растет как снежный ком. Один раз работал над приложением в котором сохранение поста вызывало 100+ колбеков в сумме. Ах да, еще скорость прохождения тестов тоже очень от этого страдает.
>>64800
Поэтому многие визжат, когда видят один единственный колбек в модели. Говно начинается с маленькой ватрушки, поэтому то, что может стать дерьмом, стараются не использовать даже в том контексте, в котором оно еще не дерьмо.
Поэтому многие визжат, когда видят один единственный колбек в модели. Говно начинается с маленькой ватрушки, поэтому то, что может стать дерьмом, стараются не использовать даже в том контексте, в котором оно еще не дерьмо.
>>64786
О, годно, не думал об этом на уровне nginx. Покурю, пасиб.
О, годно, не думал об этом на уровне nginx. Покурю, пасиб.
>>64693
Это единственное основание для разделения? Потому что всего перечисленного в заказе быть и близко не должно, это отдельные сущности.
Ну я посмотрел немного что там есть. И есть там походу очень не мало. И что важнее - это выработанные практикой решения, обобщенные, со стройным понятийным аппаратом. Так что если бы у меня был новый проект, я бы потратил время, чтобы разобраться и вероятно использовать его.
А самописы страдают тем, что реализуют виденье "художника".
>Cart и Order разделяй.
>В заказе еще и данные покупателя/доставки/оплаты/аллаха.
Это единственное основание для разделения? Потому что всего перечисленного в заказе быть и близко не должно, это отдельные сущности.
>но я предпочитаю самопис, т.к. у текущего проекта по ИМ очень специфичная бизнес-логика
Ну я посмотрел немного что там есть. И есть там походу очень не мало. И что важнее - это выработанные практикой решения, обобщенные, со стройным понятийным аппаратом. Так что если бы у меня был новый проект, я бы потратил время, чтобы разобраться и вероятно использовать его.
А самописы страдают тем, что реализуют виденье "художника".
>>65029
Не единственное. Пользователь набрал товаров в корзину и закрыл вкладку. Зашел на следующий день, решив дооформить заказ. Сессия еще жива, должна быть жива и корзина. Это еще пример на вскидку.
Половина из которых - специфика обработки заказов в штатах, т.е. те же инвойсы, итд. Впрочем, ничего против не имею. Бери комбайн и старайся кастрироваться его под своинужды. Глядишь и получится.
>Это единственное основание для разделения? Потому что всего перечисленного в заказе быть и близко не должно, это отдельные сущности.
Не единственное. Пользователь набрал товаров в корзину и закрыл вкладку. Зашел на следующий день, решив дооформить заказ. Сессия еще жива, должна быть жива и корзина. Это еще пример на вскидку.
>И что важнее - это выработанные практикой решения, обобщенные, со стройным понятийным аппаратом.
Половина из которых - специфика обработки заказов в штатах, т.е. те же инвойсы, итд. Впрочем, ничего против не имею. Бери комбайн и старайся кастрироваться его под своинужды. Глядишь и получится.
>>65092
А вот нет их там внезапно. Что подтверждает мою догадку о том, что инвойсы это какая-то квази-хуйня. Да и вообще ничего специфичного я там не нашел. Только вот оплаты заточены сугобо под карточки (как собственно и эктив-мерчант), как-будто других способов не существует. Но в это я не очень верю, видимо, бегло смотрел.
>Половина из которых - специфика обработки заказов в штатах, т.е. те же инвойсы, итд
А вот нет их там внезапно. Что подтверждает мою догадку о том, что инвойсы это какая-то квази-хуйня. Да и вообще ничего специфичного я там не нашел. Только вот оплаты заточены сугобо под карточки (как собственно и эктив-мерчант), как-будто других способов не существует. Но в это я не очень верю, видимо, бегло смотрел.
>>65092
Не понял, и чего, как это относится к разделению сущностей?
>Сессия еще жива, должна быть жива и корзина. Это еще пример на вскидку.
Не понял, и чего, как это относится к разделению сущностей?
А помните был такой сайт ruby-jobs.ru. Что с ним стало? Он же популярный довольно был.
В общем надо загрузить много файлов, заатачить к модели, и распарсить содержимое оттуда и создать еще кучу экземляров другой модели. Мне вот непонятно это лучше в ActiveJob дать или реализовать в виде сервисов? Я так понял если сделаю сервисы, то пока файля парситься будут клиент ждать будет, так?
>>65563
Проспись и переформулируй.
Проспись и переформулируй.
>>65288
Тебе, блятб, дыважды расписали что и как и где могут быть подводные. Если совсем тупенький - то столкнешься с траблами. Изволил хамить - иди на хуй. Все просто.
Тебе, блятб, дыважды расписали что и как и где могут быть подводные. Если совсем тупенький - то столкнешься с траблами. Изволил хамить - иди на хуй. Все просто.
>>65744
Элик это будущее. Мне он так зашел, что я активно его продвигаю в моем круге и челикам он тоже заходит. Пока у меня только пару пет проджектов, если через месяц уговорим заказчика работать с эликом - то и на проде появится. Как раз новый проект начнем.
>Да пошел он нахуй, говнюк этот.
Элик это будущее. Мне он так зашел, что я активно его продвигаю в моем круге и челикам он тоже заходит. Пока у меня только пару пет проджектов, если через месяц уговорим заказчика работать с эликом - то и на проде появится. Как раз новый проект начнем.
И вообще пора бы уже заводить тред руби & элик.
>>65983
Где можно погуглить вашу контору на предмет вакансий?
Где можно погуглить вашу контору на предмет вакансий?
>>65759
Нет ты!
Нет ты!
>>66056
Полумертвое говно без задач. Я пару лет назад в эликсир тред когда он еще не умер подробно расписывал почему эликсир параша, но сейчас мне лень искать эту пасту. Если тебе не хватает производительности руби (а других причин выбрать эликсир вместо руби почти нету), то просто бери котлин/скалу или ГОвно, в крайнем случае, они хоть живы.
Полумертвое говно без задач. Я пару лет назад в эликсир тред когда он еще не умер подробно расписывал почему эликсир параша, но сейчас мне лень искать эту пасту. Если тебе не хватает производительности руби (а других причин выбрать эликсир вместо руби почти нету), то просто бери котлин/скалу или ГОвно, в крайнем случае, они хоть живы.
>>66077
Ах да, за ЭЛИК отдельно тебя обоссал.
Ах да, за ЭЛИК отдельно тебя обоссал.
>>66081
Мда, вот бы теперь еще найти где симку купить, чтобы им пользоваться.
Мда, вот бы теперь еще найти где симку купить, чтобы им пользоваться.
>>66077
Чего? По всему миру есть активные конференции и жобы.
котлин только в ведре, скала параша, говно создано чтобы завести аутентификацию на сервер и все. Нет никаких нормальных утилит, чтобы решать задачи.
А феникс спокойно их решает, рельсы же забрызганное говно, к тому же еще и медленное.
>Полумертвое говно без задач.
Чего? По всему миру есть активные конференции и жобы.
>то просто бери котлин/скалу или ГОвно, в крайнем случае, они хоть живы.
котлин только в ведре, скала параша, говно создано чтобы завести аутентификацию на сервер и все. Нет никаких нормальных утилит, чтобы решать задачи.
А феникс спокойно их решает, рельсы же забрызганное говно, к тому же еще и медленное.
>>66095
В несколько раз меньше, чем даже на руби. И за последний год похоже падает. Если посмотреть developer survey от SO, то в 2017 эликсир был и в most loved, и в most wanted, в most popular (хоть и не очень высоко), в 2018 его уже нигде нету. Пунктов в рейтингах за оба года одинаковое количество.
В JVM-мирке у тебя нету никаких утилит? Ну это вообще пушка. Что у тебя там за такие охуительные задачи, которые только эликсир может решить? Только не пиши про 100к коннектов на один сервер.
Достаточно быстрое для 99% задач.
>Чего? По всему миру есть активные конференции и жобы.
В несколько раз меньше, чем даже на руби. И за последний год похоже падает. Если посмотреть developer survey от SO, то в 2017 эликсир был и в most loved, и в most wanted, в most popular (хоть и не очень высоко), в 2018 его уже нигде нету. Пунктов в рейтингах за оба года одинаковое количество.
>Нет никаких нормальных утилит, чтобы решать задачи
В JVM-мирке у тебя нету никаких утилит? Ну это вообще пушка. Что у тебя там за такие охуительные задачи, которые только эликсир может решить? Только не пиши про 100к коннектов на один сервер.
>к тому же еще и медленное.
Достаточно быстрое для 99% задач.
>>66099
жвм мирок я использую не в беке.
меньше кода пишу
руби отсасывает даже от жвм. И не говори что это не правда.
>В JVM-мирке у тебя нету никаких утилит?
жвм мирок я использую не в беке.
>Что у тебя там за такие охуительные задачи, которые только эликсир может решить?
меньше кода пишу
>Достаточно быстрое для 99% задач.
руби отсасывает даже от жвм. И не говори что это не правда.
>>66301
Version manager завезли для эликсира или все еще нет? Если нет, но это говно идет нахуй.
Version manager завезли для эликсира или все еще нет? Если нет, но это говно идет нахуй.
>>66313
твирпикс/рутракер
твирпикс/рутракер
>>66311
Эм, давно уже.
Эм, давно уже.
>>24437 (OP)
Сап, рубиновые, хочу попробовать стать таким же модным как вы, но не хочу читать книжки для совсем начинающих
Есть опыт спринга и жабки, скажите мб кто нить перекатывался с них в руби, как перекатиться проще всего?
Сап, рубиновые, хочу попробовать стать таким же модным как вы, но не хочу читать книжки для совсем начинающих
Есть опыт спринга и жабки, скажите мб кто нить перекатывался с них в руби, как перекатиться проще всего?
>>67147
Прочитай Eloquent Ruby (первые главы можно просто пролистывать, смотря только примеры кода), потом RoR Guides от корки до корки (главы про assets pipeline и js в рельсах можно скипнуть). Все, пили пет-проекты, там уж походу разберешься.
Можно еще код какого-нибудь mastodon посмотреть, у них многовато кода в модели напихано, но в целом все довольно прилично.
>>67237
Уебывай в свой мертвый тред, эликсиродебил.
Прочитай Eloquent Ruby (первые главы можно просто пролистывать, смотря только примеры кода), потом RoR Guides от корки до корки (главы про assets pipeline и js в рельсах можно скипнуть). Все, пили пет-проекты, там уж походу разберешься.
Можно еще код какого-нибудь mastodon посмотреть, у них многовато кода в модели напихано, но в целом все довольно прилично.
>>67237
Уебывай в свой мертвый тред, эликсиродебил.
>>67269
Да, но контора теперь хочет на эликсире писать. Поэтому я бы советовал учить его.
Да, но контора теперь хочет на эликсире писать. Поэтому я бы советовал учить его.
>>67269
Нет. Я как вкатился на руби так и пишу на нем. Но в последние пару лет добавилось в стек много ноды и не очень много котлина (на беке, к счастью, а не на мобилках).
Нет. Я как вкатился на руби так и пишу на нем. Но в последние пару лет добавилось в стек много ноды и не очень много котлина (на беке, к счастью, а не на мобилках).
>>67811
Видимо у вас проект рассчитан на посещаймость в 100 человек.
Видимо у вас проект рассчитан на посещаймость в 100 человек.
>>67878
Руби даже название для своей системы сборки самостоятельно придумать не может и тырит его (как и все остальное) у коммон лиспа (и тырит наверняка криво, как и все остальное). Нахуй так жить?
Руби даже название для своей системы сборки самостоятельно придумать не может и тырит его (как и все остальное) у коммон лиспа (и тырит наверняка криво, как и все остальное). Нахуй так жить?
>>68092
asdf это универсальный менеджер версии с плагинами для кучи языков, написан он на баше и никакого отношения к руби он не имеет. Да и как там что-то называлось в мертволиспе никого не волнует, ты бы еще из-за пересечения названий с какой-нибудь либой на фортране возмущался, дедуль.
asdf это универсальный менеджер версии с плагинами для кучи языков, написан он на баше и никакого отношения к руби он не имеет. Да и как там что-то называлось в мертволиспе никого не волнует, ты бы еще из-за пересечения названий с какой-нибудь либой на фортране возмущался, дедуль.
9 Кб, 274x184>>68129
Пикрелейтед ссыт тебе в ротешник.
> Да и как там что-то называлось в мертволиспе никого не волнует, ты бы еще из-за пересечения названий с какой-нибудь либой на фортране возмущался, дедуль.
Пикрелейтед ссыт тебе в ротешник.
>>68170
Молодец, хорошо подъебал.
Молодец, хорошо подъебал.
>>68129
asdf появился в 2013 году. Не шаришь - лучше промолчи.
Да, правда никто им не пользуется, кроме трех с половиной рубистов-инвалидов.
Вообще, говнина вместо нормального пекедж менеджера - это отличный аргумент против рубипитонодрисни. С жс еще ладно, там просто альтернатив нет и приходится страдать, но в 2k!9 самостоятельно себя обрекать на еблю с зависимостями, когда эта проблема уже давно решена во всех нормальных языках - это просто верх борщехлебства.
>ы бы еще из-за пересечения названий с какой-нибудь либой на фортране возмущался
asdf появился в 2013 году. Не шаришь - лучше промолчи.
>asdf это универсальный менеджер версии с плагинами для кучи языков
Да, правда никто им не пользуется, кроме трех с половиной рубистов-инвалидов.
Вообще, говнина вместо нормального пекедж менеджера - это отличный аргумент против рубипитонодрисни. С жс еще ладно, там просто альтернатив нет и приходится страдать, но в 2k!9 самостоятельно себя обрекать на еблю с зависимостями, когда эта проблема уже давно решена во всех нормальных языках - это просто верх борщехлебства.
>>68479
Тебе самому тогда стоит помолчать. Это не пекедж менеджер. Это менеджер версий рантаймов, то есть он позволяет устанавливать кучу разных версий руби/питона/ноды/рандомнойхуиты. С появлением докера надобности в подобном стало, конечно, по-меньше, но все-равно иногда полезная штука.
Для пекедж менеджмента у руби есть божественный bundler, который наголову выше и npm и pipenv.
Ах да и коммон лисповский asdf появился в 2001.
>Не шаришь - лучше промолчи
>Вообще, говнина вместо нормального пекедж менеджера - это отличный аргумент против рубипитонодрисни
Тебе самому тогда стоит помолчать. Это не пекедж менеджер. Это менеджер версий рантаймов, то есть он позволяет устанавливать кучу разных версий руби/питона/ноды/рандомнойхуиты. С появлением докера надобности в подобном стало, конечно, по-меньше, но все-равно иногда полезная штука.
Для пекедж менеджмента у руби есть божественный bundler, который наголову выше и npm и pipenv.
Ах да и коммон лисповский asdf появился в 2001.
>>68553
Тем что работает для кучи разных языков, а не только для руби. Мне он заменил rvm и nvm.
Тем что работает для кучи разных языков, а не только для руби. Мне он заменил rvm и nvm.
>>68554
Спс, буду иметь в виду.
Спс, буду иметь в виду.
>>68531
Ох, так я тебе и говорю о том, что в нормальных языках версией языка в текущем проекте заведует пекедж менеджер (а для системных зависимостей тут конечно докер).
Наголову выше мочи и говна, ну ок.
Ну тогда это действительно что-то уровня фортрана, извени, я был неправ, это все меняет.
>Это не пекедж менеджер. Это менеджер версий рантаймов
Ох, так я тебе и говорю о том, что в нормальных языках версией языка в текущем проекте заведует пекедж менеджер (а для системных зависимостей тут конечно докер).
>который наголову выше и npm и pipenv
Наголову выше мочи и говна, ну ок.
>Ах да и коммон лисповский asdf появился в 2001.
Ну тогда это действительно что-то уровня фортрана, извени, я был неправ, это все меняет.
>>67291
Котлин на бэке? Платон?
Котлин на бэке? Платон?
>>66077
Сильное заявление
Можно конкретный пример?
Просто не такой распиаренный как го, в остальном прекрасный инструмент под свои нужды, отличная эволюция эрланга
Ну и фп не для всех
Сильное заявление
Можно конкретный пример?
Просто не такой распиаренный как го, в остальном прекрасный инструмент под свои нужды, отличная эволюция эрланга
Ну и фп не для всех
>>69814
Увы, давно прошло время когда языки без компаний взлетали. Судя по ред монкс элик растет, но его можно щупать лет через 5-10 когда действительно проекты появятся. Руби тоже помирает. А котлин будет жить, потому что жид брейнс вливает колоссальное бабло туда. А в элик кто вливает? Никто.
мимо.
Увы, давно прошло время когда языки без компаний взлетали. Судя по ред монкс элик растет, но его можно щупать лет через 5-10 когда действительно проекты появятся. Руби тоже помирает. А котлин будет жить, потому что жид брейнс вливает колоссальное бабло туда. А в элик кто вливает? Никто.
мимо.
>>69890
закрывайте тред
закрывайте тред
Только начал изучать руби. Есть задача: в метод передается String, в котором есть переходы на новую строку. Мне нужно найти строку, в которой, например, есть слово "foo".
Не знаю как разделить String.
И еще если мне не известно число переходов на новую строку, то надо будет обрезанные строки складывать в массив?
Не знаю как разделить String.
И еще если мне не известно число переходов на новую строку, то надо будет обрезанные строки складывать в массив?
>>71669
https://ruby-doc.org/core-2.2.0/String.html#method-i-split
foo надо искать регулярным выражением бзв
https://ruby-doc.org/core-2.2.0/String.html#method-i-split
foo надо искать регулярным выражением бзв
>>71677
Да-да, уже сам дочитал до сплита. Аригато.
foo ищу через include?
Я так понимаю можно же ловить тру типа:
if strs[x].include?('foo') == true do something
Да-да, уже сам дочитал до сплита. Аригато.
foo ищу через include?
Я так понимаю можно же ловить тру типа:
if strs[x].include?('foo') == true do something
>>71712
Решил уже эту задачу и застрял на следующей.
Есть логи формата ip - - [date time] "POST address HTTP/1.1" randomint
Надо переформатировать ее в вид date time FROM ip TO address
Почитал про match, про regexp, попробовал написать свой, берущий date time, т.к. показалось это самым простым, но походу я вообще не одупляю как они пишутся, потому как постоянно ловлю nil.
Решил уже эту задачу и застрял на следующей.
Есть логи формата ip - - [date time] "POST address HTTP/1.1" randomint
Надо переформатировать ее в вид date time FROM ip TO address
Почитал про match, про regexp, попробовал написать свой, берущий date time, т.к. показалось это самым простым, но походу я вообще не одупляю как они пишутся, потому как постоянно ловлю nil.
>>71725
ну так почитай какой-нибудь гайд по регекс епта
ну так почитай какой-нибудь гайд по регекс епта
>>71786
Спасибо, на самом деле классная вещь.
>>71725
Вроде написал метод, теперь осталось пасснуть проверку рубокопа на дефолтном конфиге, потому как он выдает ABCSize [22.69/15]
Код: https://pastebin.com/GdPXZqHG
Спасибо, на самом деле классная вещь.
>>71725
Вроде написал метод, теперь осталось пасснуть проверку рубокопа на дефолтном конфиге, потому как он выдает ABCSize [22.69/15]
Код: https://pastebin.com/GdPXZqHG
>>72034
Все, решил. Подсказали на стаке.
Все, решил. Подсказали на стаке.
>>73328
Разжёванной до какого уровня? Документация и книжки такого уровня как у руби и рельс ещё поискать над.
Разжёванной до какого уровня? Документация и книжки такого уровня как у руби и рельс ещё поискать над.
Пожалуйста посоветуйте, как сделать нормальную авторизацию на Rails + React. Я уже задолбался с девайсом, такая хрень.
>>73412
Можешь попробовать https://auth0.com/
Или сам пили JWT авторизацию
ie. https://medium.com/binar-academy/rails-api-jwt-authentication-a04503ea3248
Можешь попробовать https://auth0.com/
Или сам пили JWT авторизацию
ie. https://medium.com/binar-academy/rails-api-jwt-authentication-a04503ea3248
>>73461
спасибо
спасибо
>>73569
в рельсах нехер делать разбираться
в рельсах нехер делать разбираться
>>73838
Бразильцы знатно переусложнили, понимаю. С другой стороны гайдов по Devise оч много.
https://github.com/plataformatec/devise/wiki
https://habr.com/ru/post/208056/
https://www.sitepoint.com/devise-authentication-in-depth/
https://medium.freecodecamp.org/lets-create-an-intermediate-level-ruby-on-rails-application-d7c6e997c63f
Попробуй спуститься на уровень ниже и разобраться как работает Warden.
Если не хочешь девайс попробуй сам сделать с has_secure_password: https://gist.github.com/iscott/4618dc0c85acb3daa5c26641d8be8d0d
Бразильцы знатно переусложнили, понимаю. С другой стороны гайдов по Devise оч много.
https://github.com/plataformatec/devise/wiki
https://habr.com/ru/post/208056/
https://www.sitepoint.com/devise-authentication-in-depth/
https://medium.freecodecamp.org/lets-create-an-intermediate-level-ruby-on-rails-application-d7c6e997c63f
Попробуй спуститься на уровень ниже и разобраться как работает Warden.
Если не хочешь девайс попробуй сам сделать с has_secure_password: https://gist.github.com/iscott/4618dc0c85acb3daa5c26641d8be8d0d
>>73295
не сравнится с питоном и пхп ,шоб можно спросить на как дваче
не сравнится с питоном и пхп ,шоб можно спросить на как дваче
>>73406
не сравниться с джанговской
не сравниться с джанговской
>>74796
Ну например в Django гораздо легче отстрелить себе ногу и понаписать говнокода на мой взгляд. Я бы не стал давать его в руки нубов.
Вообще это всё вкусовщина.
Ну например в Django гораздо легче отстрелить себе ногу и понаписать говнокода на мой взгляд. Я бы не стал давать его в руки нубов.
Вообще это всё вкусовщина.
>>75020
а в рубене МАААГИЯ
а в рубене МАААГИЯ
>>75034
Что значит какие? А какие тебе нужны?
БОльшая часть гемов работает на всех платформа, но скорее всего понадобится напильник.
Впрочем я бы не советовал чистую винду. Используй докер или WSL.
Что значит какие? А какие тебе нужны?
БОльшая часть гемов работает на всех платформа, но скорее всего понадобится напильник.
Впрочем я бы не советовал чистую винду. Используй докер или WSL.
>>75051
Если ты про докер, то вообще без разницы. Ты не будешь его видеть;
Если про настоящую виртуалку, то Ubuntu или Mint норм.
Если тебе не нужен интерфейс, то Debian.
Если ты про докер, то вообще без разницы. Ты не будешь его видеть;
Если про настоящую виртуалку, то Ubuntu или Mint норм.
Если тебе не нужен интерфейс, то Debian.
>>75059
я пытался поднять виртуалку на минте-тормаза,а ставить рядом с виндой прроблемы из-за уефи
я пытался поднять виртуалку на минте-тормаза,а ставить рядом с виндой прроблемы из-за уефи
>>75062
Не совсем понимаю вопрос. Думаю ответ — да.
Пример из документации
$ docker run -it --rm --name my-running-script -v "$PWD":/usr/src/myapp -w /usr/src/myapp ruby:2.5 ruby your-daemon-or-script.rb
Не совсем понимаю вопрос. Думаю ответ — да.
Пример из документации
$ docker run -it --rm --name my-running-script -v "$PWD":/usr/src/myapp -w /usr/src/myapp ruby:2.5 ruby your-daemon-or-script.rb
>>75062
Попробуй лучше https://docs.microsoft.com/en-us/windows/wsl/install-win10
Будет сильно проще чем с докером.
Попробуй лучше https://docs.microsoft.com/en-us/windows/wsl/install-win10
Будет сильно проще чем с докером.
>>75273
Поэтому похоронят их рядом как близких
Поэтому похоронят их рядом как близких
>>76056
Чтобы хранить глобальное состояние класса и всех его потомков. Например там может быть какой-нибудь кэш который требуется всей иерархии классов.
В чистом виде редко используется потому что, как и любое глобальное состояние, требует дисциплины. В Rails есть хелпер class_attribute который делает примерно тоже самое, но не имеет побочек (дочерний класс не может поменять состояние родительского).
Чтобы хранить глобальное состояние класса и всех его потомков. Например там может быть какой-нибудь кэш который требуется всей иерархии классов.
В чистом виде редко используется потому что, как и любое глобальное состояние, требует дисциплины. В Rails есть хелпер class_attribute который делает примерно тоже самое, но не имеет побочек (дочерний класс не может поменять состояние родительского).
>>76059
Блоки это такой синтаксис для передачи анонимного колбека как параметра внутрь другого метода.
В JS:
[1,2,3].map(function(i) { i 2 })
В Ruby:
[1,2,3].map { i 2 }
не совсем, но такое объяснение сойдёт
Блоки это такой синтаксис для передачи анонимного колбека как параметра внутрь другого метода.
В JS:
[1,2,3].map(function(i) { i 2 })
В Ruby:
[1,2,3].map { i 2 }
не совсем, но такое объяснение сойдёт
>>76070
Функция может принимать другую функцию как аргумент. Это аргумент обычно именуется колбеком.
про анонимность не важно
Функция может принимать другую функцию как аргумент. Это аргумент обычно именуется колбеком.
про анонимность не важно
>>76082
В PHP ты можешь определить такую функцию:
function modify_array($arr, $callback) {
$result = [];
for ($i = 0; $i < count($arr); $i++) {
$result[$i] = $callback($arr[$i]);
}
return $result;
}
Она принимает 2 аргумента: какой-то произвольный массив ($arr) и какой-то произвольную функцию-обработчик ($callback).
Дальше она создаёт пустой массив $result; затем начинает обходить $arr и каждый элемент исходного массива $arr[$i] передаёт
в функцию-обработчик $callback($arr[$i]). Результат работы обработчика записывается в $result[$i].
В конце работы функции получается, что ты прменил какое преобразование к каждому элементу исходного массива.
Вот как можно использовать:
$my_callback = function($i) {
return $i + 1;
}
modify_array([1, 2, 3], $my_callback);
Вернёт: [2, 3, 4]
В PHP ты можешь определить такую функцию:
function modify_array($arr, $callback) {
$result = [];
for ($i = 0; $i < count($arr); $i++) {
$result[$i] = $callback($arr[$i]);
}
return $result;
}
Она принимает 2 аргумента: какой-то произвольный массив ($arr) и какой-то произвольную функцию-обработчик ($callback).
Дальше она создаёт пустой массив $result; затем начинает обходить $arr и каждый элемент исходного массива $arr[$i] передаёт
в функцию-обработчик $callback($arr[$i]). Результат работы обработчика записывается в $result[$i].
В конце работы функции получается, что ты прменил какое преобразование к каждому элементу исходного массива.
Вот как можно использовать:
$my_callback = function($i) {
return $i + 1;
}
modify_array([1, 2, 3], $my_callback);
Вернёт: [2, 3, 4]
>>76082
В PHP ты можешь определить такую функцию:
function modify_array($arr, $callback) {
$result = [];
for ($i = 0; $i < count($arr); $i++) {
$result[$i] = $callback($arr[$i]);
}
return $result;
}
Она принимает 2 аргумента: какой-то произвольный массив ($arr) и какой-то произвольную функцию-обработчик ($callback).
Дальше она создаёт пустой массив $result; затем начинает обходить $arr и каждый элемент исходного массива $arr[$i] передаёт
в функцию-обработчик $callback($arr[$i]). Результат работы обработчика записывается в $result[$i].
В конце работы функции получается, что ты прменил какое преобразование к каждому элементу исходного массива.
Вот как можно использовать:
$my_callback = function($i) {
return $i + 1;
}
modify_array([1, 2, 3], $my_callback);
Вернёт: [2, 3, 4]
В PHP ты можешь определить такую функцию:
function modify_array($arr, $callback) {
$result = [];
for ($i = 0; $i < count($arr); $i++) {
$result[$i] = $callback($arr[$i]);
}
return $result;
}
Она принимает 2 аргумента: какой-то произвольный массив ($arr) и какой-то произвольную функцию-обработчик ($callback).
Дальше она создаёт пустой массив $result; затем начинает обходить $arr и каждый элемент исходного массива $arr[$i] передаёт
в функцию-обработчик $callback($arr[$i]). Результат работы обработчика записывается в $result[$i].
В конце работы функции получается, что ты прменил какое преобразование к каждому элементу исходного массива.
Вот как можно использовать:
$my_callback = function($i) {
return $i + 1;
}
modify_array([1, 2, 3], $my_callback);
Вернёт: [2, 3, 4]
>>76101
Я думаю тебе пока рано браться за тему с функциями высшего порядка.
Думай о блоках как о дополнительном синтаксисе для не которых функций.
Я думаю тебе пока рано браться за тему с функциями высшего порядка.
Думай о блоках как о дополнительном синтаксисе для не которых функций.
>>76124
где можно в сети задать вопрос и получить ответ?только не стековерфлоу-там тупые вопросы морозят
где можно в сети задать вопрос и получить ответ?только не стековерфлоу-там тупые вопросы морозят
>>76138
Никогда не задумывался об этом.
Здесь можно; я знаю есть телеграмм каналы; есть reddit; есть freecodecamp
Никогда не задумывался об этом.
Здесь можно; я знаю есть телеграмм каналы; есть reddit; есть freecodecamp
>>76142
формат двача мне нравиться,но в этом треде как в склепе.телеграмм заблокирован,а что на реддите?
формат двача мне нравиться,но в этом треде как в склепе.телеграмм заблокирован,а что на реддите?
>>76155
Если у тебя вопросы по основам, то тебе не важно какой язык.
Если у тебя вопросы конкретно по Ruby, то эта книжка ответит на бОльшую часть: https://rucont.ru/file.ashx?guid=a25197f9-332a-40e6-a102-c8a4cad0124b
Если у тебя вопросы по основам, то тебе не важно какой язык.
Если у тебя вопросы конкретно по Ruby, то эта книжка ответит на бОльшую часть: https://rucont.ru/file.ashx?guid=a25197f9-332a-40e6-a102-c8a4cad0124b
>>76160
у меня есть книги по руби,могу немного в англ шоб читать статьи в инете,но бывает что авторы очень херово объясняют
у меня есть книги по руби,могу немного в англ шоб читать статьи в инете,но бывает что авторы очень херово объясняют
>>76168
Хорошо! Ты проходил какие-нибудь гайды по рельсам уже? Знаменитый How to build a blog in 15 minutes with Rails?
Хорошо! Ты проходил какие-нибудь гайды по рельсам уже? Знаменитый How to build a blog in 15 minutes with Rails?
>>76175
Тогда придумай себе какую-нибудь цель, типа написать на Ruby калькулятор. Изучать язык в отрыве от производства бессмысленно.
Тогда придумай себе какую-нибудь цель, типа написать на Ruby калькулятор. Изучать язык в отрыве от производства бессмысленно.
>>76659
По виду он не достаточно opinionated и не достаточно форсит правильную архитектуру. В итоге если дать Django новичку, то он превратит всё в цирк c конями и PHP. Я могу ошибаться т.к. никогда не работал плотно с Django, но мой опыт кричит об этом.
Та самая пресловутая "магия" в рельсах отстрелит тебе голову, если ты попытаешься отстрелить себе ногу и отойти от общепринятых норм. Как ни странно в случае с новичками это сильно помогает.
По виду он не достаточно opinionated и не достаточно форсит правильную архитектуру. В итоге если дать Django новичку, то он превратит всё в цирк c конями и PHP. Я могу ошибаться т.к. никогда не работал плотно с Django, но мой опыт кричит об этом.
Та самая пресловутая "магия" в рельсах отстрелит тебе голову, если ты попытаешься отстрелить себе ногу и отойти от общепринятых норм. Как ни странно в случае с новичками это сильно помогает.
>>76871
Это показатель на сколько развита всякая автоматизация типичных задач в рельсах. Это не показатель насколько релсы хороши и какие возможности они имеют. Просто одна из фич: смотрите я могу сделать простейший CRUD прямо из командной строки.
Это показатель на сколько развита всякая автоматизация типичных задач в рельсах. Это не показатель насколько релсы хороши и какие возможности они имеют. Просто одна из фич: смотрите я могу сделать простейший CRUD прямо из командной строки.
>>76874
Нет, не пиздец. Но тебе будет не комфортно, если ты начнёшь класть код не туда куда положено или делать всякие глупости.
Рельсы пассивно-агресивны и с ними нужно сотрудничать иначе они будут тебя саботировать. Это не значит что ты чего-то не можешь сделать (или что ты там удумал?) или как-то ограничен.
https://dhh.dk/2012/rails-is-omakase.html
К чему вообще все эти вопросы? Просто попробуй и посмотри понравится или нет.
Нет, не пиздец. Но тебе будет не комфортно, если ты начнёшь класть код не туда куда положено или делать всякие глупости.
Рельсы пассивно-агресивны и с ними нужно сотрудничать иначе они будут тебя саботировать. Это не значит что ты чего-то не можешь сделать (или что ты там удумал?) или как-то ограничен.
https://dhh.dk/2012/rails-is-omakase.html
К чему вообще все эти вопросы? Просто попробуй и посмотри понравится или нет.
>>76888
Мелкие улучшения качества жизни + Action Mailbox и Action Text
https://edgeguides.rubyonrails.org/6_0_release_notes.html
Мелкие улучшения качества жизни + Action Mailbox и Action Text
https://edgeguides.rubyonrails.org/6_0_release_notes.html
Ай нид хелп (я тупой).
Есть проект на актуальных рельсах с актуальным devise.
Как правильно запретить автологин пользователя после успешной регистрации? Гуглил, читал, оверрайдил родный девайсовские контроллеры и так и эдак, вносил соотв. изменения в routes.rb, нихрена не работает.
Кто-нибудь делал такое?
Есть проект на актуальных рельсах с актуальным devise.
Как правильно запретить автологин пользователя после успешной регистрации? Гуглил, читал, оверрайдил родный девайсовские контроллеры и так и эдак, вносил соотв. изменения в routes.rb, нихрена не работает.
Кто-нибудь делал такое?
>>76934
На вскидку:
ты можешь переопределить этот метод https://github.com/plataformatec/devise/blob/master/app/controllers/devise/registrations_controller.rb#L105
На вскидку:
ты можешь переопределить этот метод https://github.com/plataformatec/devise/blob/master/app/controllers/devise/registrations_controller.rb#L105
>>76936
О, встречал на стэковерфлоу такой момент. там переопределяли как:
def sign_up(resource_name, resource)
sign_up(resource_name, resource)
end
Показалось чем-то слегка фантасмогоричным, но попробую.
О, встречал на стэковерфлоу такой момент. там переопределяли как:
def sign_up(resource_name, resource)
sign_up(resource_name, resource)
end
Показалось чем-то слегка фантасмогоричным, но попробую.
>>76861
Это реальность на любом фреймворке любого языка, и до кучи, на половине библиотек.
Это реальность на любом фреймворке любого языка, и до кучи, на половине библиотек.
>>76945
Не ну до этого додуматься я в состоянии, уже свою логику нужную вставил и нотис об удачном сайнапе убрал. Благодарствую.
Не ну до этого додуматься я в состоянии, уже свою логику нужную вставил и нотис об удачном сайнапе убрал. Благодарствую.
>>76945
И в догонку, если не сложно: я редирекчу пользователя после регистрацию на условную pages/success с информацией о дальнейших действиях. Естественно, эта страница по прямому урлу доступна всем и кждому. А как мне сделать ее достпной только человеку, прошедшему регистрацию, при условии того, что я не логиню его автоматически?
Понимаю, что проще тупо скинуть подтверждение на почту, но хотелось бы и немедленный визуальный фидбек предоставить.
И в догонку, если не сложно: я редирекчу пользователя после регистрацию на условную pages/success с информацией о дальнейших действиях. Естественно, эта страница по прямому урлу доступна всем и кждому. А как мне сделать ее достпной только человеку, прошедшему регистрацию, при условии того, что я не логиню его автоматически?
Понимаю, что проще тупо скинуть подтверждение на почту, но хотелось бы и немедленный визуальный фидбек предоставить.
>>76966
А, не-не, я действительно тупой.
И тема с оверрайдамини к чему. Пусть себе логинятся, надо тупо редиректить на страницу с настройками акка, где и прописать все, что нужно, заодно дать возможность разлогиниться.
Ну чтож, опыт - сын ошибок трудных и не всегда вменяемого тз.
А, не-не, я действительно тупой.
И тема с оверрайдамини к чему. Пусть себе логинятся, надо тупо редиректить на страницу с настройками акка, где и прописать все, что нужно, заодно дать возможность разлогиниться.
Ну чтож, опыт - сын ошибок трудных и не всегда вменяемого тз.
>>76936
Вообще, действительно спасибо. Меня не хватило на самое простое, что могло быть - просмотр исходников. Посыпаю голову пеплом.
Вообще, действительно спасибо. Меня не хватило на самое простое, что могло быть - просмотр исходников. Посыпаю голову пеплом.
447 Кб, 512x512Сап. Подскажите какой итератор может сравнить в блоке элемент со следующим элементом?
Вот я знаю только each_with_index, а следующий элемент потом в блоке arr[index+1], проблема в том что в конце массива возвращает nil, из-за чего надо проверять unless arr[index+1].nil?
Но может есть получше вариант?
Вот я знаю только each_with_index, а следующий элемент потом в блоке arr[index+1], проблема в том что в конце массива возвращает nil, из-за чего надо проверять unless arr[index+1].nil?
Но может есть получше вариант?
Создаётся впечатление что в руби больше вакансий и меньше конкуренция. Может хоть туда меня возьмут? Стоит изучать?
>>77518
нет
нет
83 Кб, 1676x292Что это такое на пикрил <<- ?
Смотрю скрипт установки зависимостей для пакета через homebrew, если это важно
Смотрю скрипт установки зависимостей для пакета через homebrew, если это важно
>>77715
Это heredoc. Мне кажется, даже в Си можно было такое делать.
https://www.rubyguides.com/2018/11/ruby-heredoc/
Это heredoc. Мне кажется, даже в Си можно было такое делать.
https://www.rubyguides.com/2018/11/ruby-heredoc/
>>77742
Спасибо, а где можно почитать перечень глобальных классов, переменных, которые доступны с самого начала скрипта?
Вот эти всякие puts, abort(которая как я понял из класса Kernel) и т.д.
Спасибо, а где можно почитать перечень глобальных классов, переменных, которые доступны с самого начала скрипта?
Вот эти всякие puts, abort(которая как я понял из класса Kernel) и т.д.
>>77896
Да, Kernel
https://ruby-doc.org/core-2.6.2/Kernel.html
Вся базовые класса там же ^
Стандартная библиотека здесь: https://ruby-doc.org/stdlib-2.6.2/
Да, Kernel
https://ruby-doc.org/core-2.6.2/Kernel.html
Вся базовые класса там же ^
Стандартная библиотека здесь: https://ruby-doc.org/stdlib-2.6.2/
>>79518
а они есть
а они есть
какие отличия у руби от питона?
Это бот что ли эти вопросы пишет, чтобы тред не утонул?
Мне скучно отвечать на однострочные общие вопросы без контекста.
Мне скучно отвечать на однострочные общие вопросы без контекста.
>>80362
нужно как то поддерживать живой труп
нужно как то поддерживать живой труп
>>83303
ну легаси говно во времена хайпа надо же поддерживать
ну легаси говно во времена хайпа надо же поддерживать
Возможно я слишком усложняю задачу, у которой должно быть решение проще, но как из класса передать во второй класс объект первого класса?
У меня есть класс, допустим, слушатель, который "подписывается" на класс эвент-мейкер. Когда эвент-мейкер собсна делает эвент мне надо слушателю передать время и значения эвента. Поиск по Notification паттерну нашел лишь вопросы по апишкам всяких фейсбуков и их уведомлений.
Единственное до чего я додумался, это при вызове метода subscribe_to класса Listener записывать в переменную-массив класса Eventmaker текущий объект класса Listener, а при создании эвента в классе Eventmaker проходить по массиву и передавать notification в каждый объект.
У меня есть класс, допустим, слушатель, который "подписывается" на класс эвент-мейкер. Когда эвент-мейкер собсна делает эвент мне надо слушателю передать время и значения эвента. Поиск по Notification паттерну нашел лишь вопросы по апишкам всяких фейсбуков и их уведомлений.
Единственное до чего я додумался, это при вызове метода subscribe_to класса Listener записывать в переменную-массив класса Eventmaker текущий объект класса Listener, а при создании эвента в классе Eventmaker проходить по массиву и передавать notification в каждый объект.
>>84962
subscribe должен быть в лисенере.
Попробую объяснить на каком-нибудь реальном предмете. Есть у нас телеграм-канал (класс) и пользователь (класс). Пользователь подписывается на телеграм-канал (подписка это метод класса пользователя) и после этого каждый новый пост в телеграм-канале (метод класса телеграм-канал, публикуюищй запись) отправляет всем подписчикам (классам пользователь, которые подписались) уведомление с содержанием поста. Подписчик может получить все уведомления (метод класса пользователь).
subscribe должен быть в лисенере.
Попробую объяснить на каком-нибудь реальном предмете. Есть у нас телеграм-канал (класс) и пользователь (класс). Пользователь подписывается на телеграм-канал (подписка это метод класса пользователя) и после этого каждый новый пост в телеграм-канале (метод класса телеграм-канал, публикуюищй запись) отправляет всем подписчикам (классам пользователь, которые подписались) уведомление с содержанием поста. Подписчик может получить все уведомления (метод класса пользователь).
>>88972
Нет, не миф, просто ничего уникального в рельсах больше нет.
Нет, не миф, просто ничего уникального в рельсах больше нет.
Двач, я заебался. На весь интернет два с половиной примера драй-ром-параши на рельсе, и те успели устареть. Поэтому хочу у тебя спросить: как мне в контрактах провалидировать юзера на предмет его уникальности по логину? По документации, в валидациях обращаются к Users.where, но меня посылают нахуй. Нет такого метода говорят. Без валидаций создание пользователя работает.
---------------
gem 'rom-rails', '~> 2.0.0'
gem 'rom-sql', '~> 3.0.0'
gem "dry-validation", '~> 1.0.0.rc1'
gem 'dry-transaction', '~> 0.13.0'
gem 'dry-monads', '~> 1.2.0'
---------------
require 'dry-validation'
module Api
module V1
class NewUserContract < Dry::Validation::Contract
params do
required(:login).filled(:string)
end
rule(:login) do
key.failure('is already taken') if Users.where(login: values[:login]).count > 0
end
end
end
end
---------------
---------------
module Api
module V1
class Users < ROM::Relation[:sql]
gateway :default
schema(:users, infer: true)
end
end
end
---------------
---------------
gem 'rom-rails', '~> 2.0.0'
gem 'rom-sql', '~> 3.0.0'
gem "dry-validation", '~> 1.0.0.rc1'
gem 'dry-transaction', '~> 0.13.0'
gem 'dry-monads', '~> 1.2.0'
---------------
require 'dry-validation'
module Api
module V1
class NewUserContract < Dry::Validation::Contract
params do
required(:login).filled(:string)
end
rule(:login) do
key.failure('is already taken') if Users.where(login: values[:login]).count > 0
end
end
end
end
---------------
---------------
module Api
module V1
class Users < ROM::Relation[:sql]
gateway :default
schema(:users, infer: true)
end
end
end
---------------
Двач, я заебался. На весь интернет два с половиной примера драй-ром-параши на рельсе, и те успели устареть. Поэтому хочу у тебя спросить: как мне в контрактах провалидировать юзера на предмет его уникальности по логину? По документации, в валидациях обращаются к Users.where, но меня посылают нахуй. Нет такого метода говорят. Без валидаций создание пользователя работает.
---------------
gem 'rom-rails', '~> 2.0.0'
gem 'rom-sql', '~> 3.0.0'
gem "dry-validation", '~> 1.0.0.rc1'
gem 'dry-transaction', '~> 0.13.0'
gem 'dry-monads', '~> 1.2.0'
---------------
require 'dry-validation'
module Api
module V1
class NewUserContract < Dry::Validation::Contract
params do
required(:login).filled(:string)
end
rule(:login) do
key.failure('is already taken') if Users.where(login: values[:login]).count > 0
end
end
end
end
---------------
---------------
module Api
module V1
class Users < ROM::Relation[:sql]
gateway :default
schema(:users, infer: true)
end
end
end
---------------
---------------
gem 'rom-rails', '~> 2.0.0'
gem 'rom-sql', '~> 3.0.0'
gem "dry-validation", '~> 1.0.0.rc1'
gem 'dry-transaction', '~> 0.13.0'
gem 'dry-monads', '~> 1.2.0'
---------------
require 'dry-validation'
module Api
module V1
class NewUserContract < Dry::Validation::Contract
params do
required(:login).filled(:string)
end
rule(:login) do
key.failure('is already taken') if Users.where(login: values[:login]).count > 0
end
end
end
end
---------------
---------------
module Api
module V1
class Users < ROM::Relation[:sql]
gateway :default
schema(:users, infer: true)
end
end
end
---------------
>>90592
Запросы на аггрегаты пишутся внутри репозиториев. У тебя должно быть что-то типа
class UserRepo < ROM::Repository[:users]
def login_exists?(login)
user.where(login: login).count
end
end
------
key.failure('is already taken') if UserRepo.login_exists?(login: values[:login])
Запросы на аггрегаты пишутся внутри репозиториев. У тебя должно быть что-то типа
class UserRepo < ROM::Repository[:users]
def login_exists?(login)
user.where(login: login).count
end
end
------
key.failure('is already taken') if UserRepo.login_exists?(login: values[:login])
Разыскиваю "Ruby. Объектно-ориентированное проектирование, 2018", в этих ваших интернетах только 2017
>>91491
Её на русском языке судя по всему ещё не существует в электронном виде. Ищи английский вариант или читай первое издание — разница между первым и вторым минимальна.
Её на русском языке судя по всему ещё не существует в электронном виде. Ищи английский вариант или читай первое издание — разница между первым и вторым минимальна.
>>91021
Да, сработало, но пришлось в репозитории напердолить что-то типа:
---------
require 'rom-repository'
module Api
module V1
class UserRepository < ROM::Repository[:users]
commands :create
def self.login_exists?(login)
new(ROM.env).users.where(login: login).count > 0
end
end
end
end
---------
Наверняка можно сделать получше, но и так пока сойдет.
> key.failure('is already taken') if UserRepo.login_exists?(values[:login])
Да, сработало, но пришлось в репозитории напердолить что-то типа:
---------
require 'rom-repository'
module Api
module V1
class UserRepository < ROM::Repository[:users]
commands :create
def self.login_exists?(login)
new(ROM.env).users.where(login: login).count > 0
end
end
end
end
---------
Наверняка можно сделать получше, но и так пока сойдет.
>>92431
я про финальную версию,еще вчера должна выйти
я про финальную версию,еще вчера должна выйти
А может выучить рельсы?
Мимо джангист-штангист. Руби уже знаю и часто использую.
Мимо джангист-штангист. Руби уже знаю и часто использую.
>>92552
когда официально выйдет 6 рельсы
когда официально выйдет 6 рельсы
Ух, бля, ознакомительный пердолинг с драй-ром окончиль.
В некоторых местах оверинженернутая хуйняша этот ваш драй-sql, конечно. Обджект релейшен маппер над релейшен маппером стоит и погоняет.
Хотя в целом прикольненько. Мне понра
В некоторых местах оверинженернутая хуйняша этот ваш драй-sql, конечно. Обджект релейшен маппер над релейшен маппером стоит и погоняет.
Хотя в целом прикольненько. Мне понра
Тред утонул или удален.
Это копия, сохраненная 5 мая 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 5 мая 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.