Modules are collections of methods and constants. They cannot generate instances. Classes may generate instances (objects), and have per-instance state (instance variables).
Modules may be mixed in to classes and other modules. The mixed-in module’s constants and methods blend into that class’s own, augmenting the class’s functionality. Classes, however, cannot be mixed in to anything.
A class may inherit from another class, but not from a module.
A module may not inherit from anything.
Confidence=>Verification that our system behaves as it is suppose to. this can be done manually or can be automated. Automated testing is less painful and much easier because it shortened feedback loop make improving our design.
There are two fundamental purposes of testing:
1.verifying procurement specifications
2. managing risk.
First, testing is about verifying that what was specified is what was
delivered: it verifies that the product (system) meets the functional, performance,
design, and implementation requirements identified in the procurement specifications.
Second, testing is about managing risk for both the acquiring agency and the system’s
vendor/developer/integrator. The testing program is used to identify when the work has
been “completed” so that the contract can be closed, the vendor paid, and the system
shifted by the agency into the warranty and maintenance phase of the project.
What testing do for us?
- Testing improves your designs. Each target object that you test must have at least two clients: your production code, and your test case. These clients force you to decouple your code. Testing also encourages and rewards smaller, simpler methods.
- Testing reduces unnecessary code. When you write your test cases first, you get in the habit of writing only enough code to make the test case pass. You reduce the temptation to code features because you might need them later.
- Test-first development is motivating. Each test case that you write establishes a small problem. Solving that problem with code is rewarding and motivating. When I do test-driven development, the hours fly by.
- Testing allows more freedom. If you have test cases that will catch likely errors, you’ll find that you’re more willing to make improvements to your code.
I was wondering why some people are using _path and why some use _url. For example, if you have a Post resource you can write the following in your view:
[%= link_to 'List of posts', posts_path %]
or the following in the controller:
Why should I use _url in the controller. I have used _path and it seems to work.
This is an explanation I found in a forum and I quote:
*_path are for views because ahrefs are implicitly linked to the current URL. So it’d be a waste of bytes to repeat it over and over. In the controller, though, *_url is needed for redirect_to because the HTTP specification mandates that the Location: header in 3xx redirects is a complete URL
Filters are methods that are run before, after or “around” a controller action.
Filters are inherited, so if you set a filter on ApplicationController, it will be run on every controller in your application.
Before filters may halt the request cycle. A common before filter is one which requires that a user is logged in for an action to be run.
Before filters are run on requests before the request gets to the controller’s action. It can return a response itself and completely bypass the action.
The most common use of before filters is validating a user’s authentication before granting them access to the action designated to handle their request. I’ve also seen them used to load a resource from the database, check permissions on a resource, or manage redirects under other circumstances.
After filters are run after the action completes. It can modify the response. Most of the time if something is done in an after filter, it can be done in the action itself, but if there is some logic to be run after running any of a set of actions, then an after filter is a good place to do it.
Generally, I’ve seen after and around filters used for logging.
Around filters may have logic before and after the action being run. It simply yields to the action in whatever place is necessary. Note that it doesn’t need to yield to the action and may run without doing so like a before filter.
You can use around filters for exception handling, setup and teardown, and a myriad of other cases.
The truth of the matter is that Symbols are Strings, just with an important difference, Symbols are immutable. Mutable objects can be changed after assignment while immutable objects can only be overwritten. Ruby is quite unique in offering mutable Strings, which adds greatly to its expressiveness. However mutable Strings can have their share of issues in terms of creating unexpected results and reduced performance. It is for this reason Ruby also offers programmers the choice of Symbols.
So, how flexible are Symbols in terms of representing data? The answer is just as flexible as Strings.