⌘T | go to file |
⌘⌃P | go to project |
⌘R | go to methods |
⌃G | go to line |
⌘KB | toggle side bar |
⌘⇧P | command prompt |
REST stands for Representional State Transfer and is defined on Wikipedia as:
Representational state transfer (REST) is a software architectural style consisting of a coordinated set of architectural constraints applied to components, connectors, and data elements, within a distributed hypermedia system. REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements.
I think the second part of that explanation sounds like it could be quite interesting... but to me that all seems super complicated! So I've decided to try to simplify it for my own understanding. (If I have not understood something in this gist, please TELL ME!)
##Saving & Retrieving information For this section, think of a web application as a piece of software built to help people to store and access information online.
I think the most confusing thing that I have found about Ruby on Rails so far has been the transition from (trying to) write code myself to the use of the fabled "Rails Magic". So, to help my own understanding of a few core Ruby on Rails concepts, I have decided to write something on what I think is a CRITICAL topic... the idea of Convention over Configuration and why (in my mind) it is the most important thing that helps Rails become magic!
(This may be a topic that we cover in more detail in class but as I said, I'm writing this for my own understanding... I hope it helps someone else understand things too... Perhaps you can give me a hand when I'm crying next week!)
##Convention over configuration ###What does this "actually" mean...
Rails' use of strict naming conventions means a lot of core code SHOULD be in the same format whoever writes it? It could be written by a friend, colleague or a computer... it shouldn't matter because the same Rails rules apply to everyone.
This means that Rails can actually do some tasks for you! It can actually build things and write code on your behalf...
Coming from another language like PHP, this can seem like magic.
Migrations are a feature of Active Record that allows you to evolve your database schema over time. Rather than write schema modifications in pure SQL, migrations allow you to use an easy Ruby DSL to describe changes to your tables.
Another way of thinking about them is like a kind of version control (like git) for your application's database - only not as cool as Git (because Git rules).
##Each database starts empty Every database starts empty. Adding information to a database can be described as a series of steps, one after another... Migrations allow developers to save the most important steps like creating tables or adding columns. Later you can rollback to before these changes if something goes wrong, although you might lose data if you do this!
When developing websites for small to medium clients, often a decent CMS is needed to get basic CRUD functionality and authentication off the ground quickly.
I've done a little bit of research into some of the most popular CMS platforms. Here are my quick thoughts.
- Website: http://www.browsercms.org/
Deploying to Heroku | |
================== | |
group :production do | |
gem 'rails_12factor' | |
end | |
# Enable the asset pipeline | |
config.assets.enabled = true | |
config.assets.initialize_on_precompile = false |
Repost from: http://opensoul.org/2011/11/30/haml-the-unforgivable-sin/
I used HAML on several client projects and I hated it every time. There are certainly some things that are nice about it, but overall it is a net loss.
##For abstraction’s sake Abstractions are a beautiful thing. The goal of an abstraction is to reduce or factor out irrelevant details. Removing details focuses you on the problem at hand and not the underlying implementation.