The Rails philosophy is based upon three principles:
- Convention over Configuration – Common aspects of a web application are provided (i.e., preconfigured) for you, so use them, rather than fight against them! Ideally, the developer should only have to specify the unconventional aspects of the application.
- Don’t Repeat Yourself (DRY) – Every piece of information should have a single, unambiguous, authoritative representation within a system. Duplication of code fragments throughout an application can lead to logical contradictions, and in general make the application more difficult to maintain.
- Agile Development – Software development methodologies based on iterative and incremental development, where requirements and code evolve with minimal planning through self-organizing, cross-functional teams.
Convention over Configuration
A massive number of “conventions” are built into Rails, and the real trick is learning all of them. When you create a Rails application, the full web stack is “pre-wired” and ready to go.
Rails code generators follow specific naming conventions. E.g., if you use the scaffold (MVC) generator to create a Post, you get:
- – A class called Post will be created for the model, along with a corresponding table in the database that will be called posts
- – A RESTful controller called posts_controller will be created, and routes will be set up so that specific URLs will be able to perform CRUD operations on the post table in the database.
- – A posts view will be created, consisting of a set of HTML files that can be used to render the results of the CRUD operations.
- – Test fixtures, along with unit, functional, integration and performance test suites are automatically generated.
Don’t Repeat Yourself (DRY)
Every piece of information should have a single, unambiguous, authoritative representation within a system. E.g., In Rails, with ActiveRecords, once a model is specified, you don’t need to specify database column names –they’re determined from the model.
- When applied successfully, a modification to a system element does not change any other logically-unrelated system element, while elements that are logically related all change predictably and uniformly, thereby keeping them in “sync”.
- This principle makes it easier to use code generators and automatic build systems.
- Thus, DRY code is typically created by data transformations and code generators, allowing the software developer to avoid copy and paste operations.
- Following the DRY principle makes it easier to maintain large software systems.
- Agile development emphasizes working software as the primary measure of progress.
- Rails was built with agile development in mind:
- – A working application is available immediately.
- – In development mode, there are no recompile, deploy, restart cycles.
- I.e., Rails does not generally require you to stop the server; changes made to the application will be automatically picked up by the server.
- – Rails has simple tools to generate code quickly.
- – Testing is built into the Rails framework.
- Extreme programming is an agile approach that that centers around test-driven development (TDD). Behavior-driven development (BDD), a second generation agile approach, extends TDD by writing test cases in natural language that non-programmers can read. BDD focuses on obtaining a clear understanding of desired software behavior through discuss with stakeholders.
- RSpec and Cucumber are BDD tools for Ruby that we’ll use.
- Dependency injection
- Directives and Pipes
- Data binding
- HTTP Get vs. Post
- Node.js is everywhere
- MongoDB root user
- Prefer Async Script Loading
- Components, Bootstrap and DOM
- What is HEAD in git?
- Show the changes in Git.
- What is AngularJS 2?
- Confidence Interval for a Population Mean
- Accuracy vs. Precision
- Sampling Distribution
- Working with the Normal Distribution
- Standardized score - Z score
- Evaluating the Normal Distribution
- What is Nodejs? Advantages and disadvantage?
- How do I debug Nodejs applications?
- Sync directory search using fs.readdirSync