I have some command-line ruby scripts for things like pre-processing text files before uploading them and scraping data.
These scripts don't rely on the rails environment, so I don't really want to make them rake tasks with the associated overhead.
Where should I put them in my folder layout? lib/utility/ or something?
We put ours either into the top level of lib/ or we break them down further like lib/reports or lib/stats.
Related
We are sharing a build script for FAKE across a set of projects. We want to keep this one build script the same but make it possible to extend with other targets. One way I could think of doing this is by loading .fsx files if they fit a specific naming pattern like al files that matches build-*.fsx however I can't seem to think of a way to load these files dynamically. Any suggestions on how to do this or how to accomplish the desired result are all good as answers
if I could I would have done something like
#load "build-*.fsx"
It's not completely clear to me why you want to do this but maybe this will help. Refer to a single script in each project:
#load "load-build-scripts.fsx"
And then in single load-build-scripts.fsx:
#load "build-1.fsx"
#load "build-2.fsx"
#load "build-3.fsx"
...
This second file you will need to change whenever you add a new script.
It's not generally recommended to do this. Because now if these separate scripts refer to each other then some scripts will be loaded more than once. Scripts aren't really meant to be used for cases this complex.
Another option is to use FAKE as a console project instead of using scripts and the fake-cli tool. Then you can use normal .NET project dependencies.
I read this:
If you add a dir directly under app/
Do nothing. All files in this dir are eager loaded in production and
lazy loaded in development by default.
If you add a dir under app/something/
(e.g. app/models/concerns/, app/models/products/)
Ask: do I want to namespace modules and classes inside my new dir? For
example in app/models/products/ you would need to wrap your class in
module Products.
If the answer is yes, do nothing. It will just work.
If the answer is no, add config.autoload_paths += %W(
#{config.root}/app/models/products )
I want to know how Rails does this. How does it:
Load the file inside a folder (named folder_nest) in the app folder only if the contents of that file are wrapped in a module named after that folder (folder_nest module). How does this happen?
There must be some logic that says: "if the thing inside of app is a file, eager load it. If it's a folder, only load the contents of said folder if it's wrapped in a module named after said folder."
Anyone know where this logic is? How do I read Rails source code?
Also, is config/initializers eagerly loaded? Where is that logic?
Well, looks like you have a lot of questions best answered by the one question "How do I read Rails source code"
Personally, I do something like the following from the command-line:
subl `bundle show rails`
and then use the text editor (sublime in this case, textmate also works) + search, just read the code. Sometimes I'll insert "puts" statements in there to make sure I'm reading the right code and run it just to be sure.
You can answer most of your own questions about the initialization sequence, etc, that way.
I am writing test cases for ROR. The code to test one model/controller is too much . Is there anyway to break the file in different files for testing the same model/controller.
Yes you can split up tests into different files. I believe test::unit requires files to be *_test.rb.
So say you had a test file for a User model. You could have your tests broken up like:
user_validations_test.rb
user_login_test.rb
...
I know you're using test::unit but, same thing goes with RSpec, you can break up your tests into *_spec.rb files.
If you are using rspec for testing, you can simply add more than one file describing the same class. It might be reasonable to create in spec/ directory matching subdirectory, and place all spec files in there.
Under the section "Cascading Style Sheets" in M. Hartl's Rails 3 tutorial he mentions copying the CSS blueprint directory into the 'public/stylesheets' folder. My stylesheets folder resides within the assets directory. Is it reasonable to copy the blueprint directory into the 'assets/stylesheets' instead of the 'public/styleshets'? If not, what might be your suggestion? If so, are there any particular pitfalls of which you might suggest I be mindful?
He clearly suggested using Rails 3.0.1, though I am running 3.2.6. I should have followed his directions to the mark, but I had an almost impossible time getting the environment up and running on my Windows machine (MySQL conflicts, etc... ) and it just so happened that this version ended up working for me so I went with it.
Don't assume I know what I'm talking about, because I'm new to RoR, but I just spent the last few hours reading up on the asset pipeline after running into problems with it. I'll share a few things I've learned that might help you conceptualize:
Anything in public/ is left just the way it is, and server as static files directly by the web server. There are two points worth considering regarding public/ assets, though:
1) They don't get the benefits of precompiling, which include:
1a) fingerprinting - Appending an md5 hash based on file contents to the filename, so that the filename changes when the file changes, forcing caches to reload. This is useful if the file might change some day (a new version of blueprint, in your case).
1b) concatenation - The precompiler can/will combine multiple CSS or JS files into one, which makes the download faster. (Exactly what files get compiled and into how many is configurable.)
1c) minification - The precompiler removes whitespace (and other clever optimizations) to shrink down the size of your CSS/JS files.
2) I'm still trying to figure this part out, but whether something is in /app/assets and goes through precompile affects whether and how helper methods work (things like asset_tag, image_tag, and javascript_include tag, which you use in your views).
Even though I'm totally unqualified, I'm seriously considering starting my own Rails Assets Best Practices page on a wiki somewhere to start organize my thoughts. I think it's sorely lacking - I've had to dredge bits of knowledge from many places, and some of what people are suggesting I find objectionable (like modifying config files to precompile add unmanifested assets).
I have copied my stylesheet files to app/assets folder and it worked normally
I am struggling to find any real documentation on the new Rails 3 asset pipeline. I know there is a video, but I do not wish to watch an hour video in this format. I watched about 10 minutes and gained no knowledge.
So, what do I need to know about Rails 3 asset pipelines? What does this mean to my previous projects, and what does it mean to my future projects?
It means you will now be able to write css and javascript in separate files using sass and coffeescript if you want and they will be compiled into one single file in the end.
If you have like, 4 css files on your assets/stylesheets they will be concatenated and compressed and delivered on production with a single application.css file.
Same thing applies to javascript files.
More info in http://getsprockets.org/
You can get some good documentation here on rails guides here
http://edgeguides.rubyonrails.org/asset_pipeline.html
It's a great way to serve fast assets for your application. Sprockets is playing a major role in it.