Rails for Invenio admins¶
Ruby on Rails is a full development and deployment environment. I'm not going to explain it here, but just take note of some useful tips in the Invenio to Muscat migration.
How Rails deals with different software versions, or why Rails doesn't need containers¶
It has taken time for me to get the idea, but the more experience and reading I'm having with Rails, now I think that I understand it.
Each Rails application tries very hard to use only the software versions that are installed under the application directory, ignoring as much as possible everything that is outside it, including the system (Debian, in our case) defaults. Every time we do a bundle install , we install them under the current directory, and the software uses hardcoded paths to make sure that the Rails application uses that version and not any other.
If I install 3 Rails applications, like 3 Muscat instances, many pieces of software are triplicated. Before I understood that, I tried to install Debian versions of many of the Rails pieces Muscat reuses, but the fact is that Muscat has completely ignored them.
The definitive experience has been trying to install a pure Blacklight instance, without Muscat, so I can understand better it without the Muscat default values. Following the https://github.com/projectblacklight/blacklight/wiki/Quickstart guide I've got the final convincment. It is better to follow the Rails way, even if it goes against my typical practice.
Rails environment¶
Installing a Ruby on Rails environment means that: an environment. This environment consists in a database (and in the Muscat case, a Solr instance), variables, permissions, etc. So, for running maintenance scripts, instead of running plain Ruby scripts, it is useful to run rails scripts, so the database, variables, methods, utilities, etc, are already defined. For example:
https://github.com/rism-ch/muscat/tree/develop/housekeeping/correct
The difference is that, instead of running:
$ ruby myscript
You run
$ rails run myscript
Then you just write the specific logic you are interested in; opening the database, defining or importing objects, everything related to this Rails instance is ready for you, and scripts can be really small and going straight to the point, for example: https://github.com/rism-ch/muscat/blob/develop/housekeeping/correct/18_find_some_tag.rb
This is another reason why they say that working in Rails is so productive. Because it embraces not only the web interface, but also any batch or maintenance script.
Rails console¶
Calling
$ rails console
Opens a Ruby interactive prompt (irb) but with all this environment loaded.
Debugging a Rails app¶
https://youtu.be/JnQ72lZeQyI Debugging Ruby on Rails (very useful!)
The most useful tip: on the .erb pages, add debug() to show the value or a complex variable or object, like Python's pprint.pprint():
<%= debug(variable) %>
A simpler print method is this one, for scalar variables:
<%= variable.inpect %>
When I've needed to inspect a variable on a non-view method, I've used this trick to write in a file:
open('tmp/muscat-debug.log', 'a') do |f|
f.puts Time.now.to_s
f.puts 'source.rb'
f.puts "RISM::AGENCY = #{RISM::AGENCY}"
f.puts "RISM::BASE = #{RISM::BASE}"
f.puts "RISM::MARC = #{RISM::MARC}"
f.puts "RISM::EDITOR_PROFILE = #{RISM::EDITOR_PROFILE}"
f.puts @item.marc
f.puts EditorConfiguration.get_show_layout(@item)
end
Extending a Rails app¶
I'm learning, via tutorials, videos and other documents, that in the Rails world it is a common thing to do to extend an existing application. And usually it means to call rails to generate and incorporate new gems or new code. Yes, for me it has been a surprise.
An example, among dozens, this video: https://youtu.be/T5TcOyo4ocs (part of https://memphis-cs.github.io/rails-tutorial-2019/demo-04-rails-static-pages/)
Webpack, yarn and javascript tools¶
https://samuelmullen.com/articles/embracing-change-rails51-adopts-yarn-webpack-and-the-js-ecosystem/
Actualitzat per Ferran Jorba fa més de 2 anys · 9 revisions