Class names are CamelCase
.
Methods and variables are snake_case
.
Methods with a ?
suffix will return a boolean.
This is what I once wrote to a reader:
- Nand2Tetris book - http://www.nand2tetris.org/
- The paper "An Incremental Approach to Compiler Construction", by Abdulaziz Ghuloum. You can find a hosted PDF version of the paper and an implementation of its contents here: https://github.com/namin/inc\
- Jack Crenshaw's classic "LET'S BUILD A COMPILER" from 1988. Even though it's kinda dated (he's using Turbo Pascal), it's one of the great "let's roll our sleeves up and write some code" texts. Here is the PDF version: http://compilers.iecc.com/crenshaw/tutorfinal.pdf
- Then there are also the 4th and 5th chapters of Structure an Interpretation of Computer Programs (SICP), in which you'll build an interpreter and a kinda bytecode-compiler for a virtual register machine. It's a pretty abstract and seemingly alien affair (using a Lisp dialect to build a virtual register machine for a bytecode defined in Lisp, produced by a Lisp compiler, etc.), but it teaches the concepts behind the whole compiler and VM thing.
class Ticket < ActiveRecord::Base | |
belongs_to :grouper | |
belongs_to :user | |
validate :user_cant_be_blacklisted, on: :confirmation | |
validate :user_cant_double_book, on: :confirmation | |
validate :grouper_cant_be_full, on: :confirmation | |
validate :grouper_cant_have_occurred, on: :confirmation |
Inside of Rails views, you can call partial views (any view file named with an underscore as the first character) like this:
render partial: "partial_name"
You can also pass local variables, which is fantastic to ensure that your views & partials don't try to access data you didn't specifically hand to them from the controller.
@tylerhunt showed me this week that it was possible to avoid using instance variables (which are copied from the Rails controller to the corresponding Rails views) altogether by passing local variables to the view.
If your master.key has been compromised, you might want to regenerate it.
No key regeneration feature at the moment. We have to do it manually.
rails credentials:show
somewhere temporarily.config/master.key
and config/credentials.yml.enc
EDITOR=vim rails credentials:edit
in the terminal: This command will create a new master.key
and credentials.yml.enc
if they do not exist.config/credentials.yml.enc
One of the big leaps you'll have to make as a JavaScript developer is wrapping your head around Object Oriented Programming (OOP). This is tough, and that's ok because it's tough for everyone at first. When you start out with JavaScript you're taught to use functions as your primary way of organizing your code. This is fine, but you'll probably find that organizing your code around objects makes larger projects easier to accomplish and improve / maintain.
The cool thing is that what OOP amounts to is an organizational strategy. I have a set of related tasks, how do I go about starting the project and organizing my code? These tasks have some variables and functions that are used to accomplish them, so you create them and write the logic for them to interact. While you can write those out as detached functions and variables, making those variables and functions into properties and methods of an object can make the division between those tasks easier to see and maintain.
Maint
I don't have a Grand Vision for (S)CSS, but I do have some ideas.
In JavaScript (and any other "programming language"), we value cohesion and eschew coupling. To value cohesion is to say that all of the foo-related things are in the Foo
component or the app/pods/foo
pod or the lib/foo
addon. Like things are together. To eschew coupling is to say that two unrelated things should not need to know about one another. Unlike things don't rely on one another. Further reading on Cohesion & Coupling:
# based on ruby/benchmark/bm_erb_render.rb | |
require 'benchmark/ips' | |
require 'erb' | |
require 'erubi' | |
require 'erubis' | |
data = DATA.read | |
mod = Module.new | |
mod.instance_eval("def self.erb(title, content); #{ERB.new(data).src}; end", "(ERB)") |
Any GitHub wiki can be cloned by appending wiki.git
to the repo url, so the clone url for
the repo https://myorg/myrepo/
is: [email protected]/myorg/myrepo.wiki.git
(for ssh) or https://github.com/my/myrepo.wiki.git
(for https).
You make edits, and commit and push your changes, like any normal repo.
You need to clone the wiki repo and edit it on your system.