| #------------------------------------------------------------- | |
| # Git Alias Commands | |
| #------------------------------------------------------------- | |
| alias g="git status" | |
| alias ga="git add" | |
| alias gaa="git add ." | |
| alias gau="git add -u" | |
| alias gc="git commit -m" | |
| alias gca="git commit -am" | |
| alias gb="git branch" |
| Run in command line: | |
| RAILS_ENV=production rake db:create db:schema:load |
Originally published in June 2008
When hiring Ruby on Rails programmers, knowing the right questions to ask during an interview was a real challenge for me at first. In 30 minutes or less, it's difficult to get a solid read on a candidate's skill set without looking at code they've previously written. And in the corporate/enterprise world, I often don't have access to their previous work.
To ensure we hired competent ruby developers at my last job, I created a list of 15 ruby questions -- a ruby measuring stick if you will -- to select the cream of the crop that walked through our doors.
Candidates will typically give you a range of responses based on their experience and personality. So it's up to you to decide the correctness of their answer.
Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.
In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.
Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j
This method avoids merge conflicts if you have periodically pulled master into your branch. It also gives you the opportunity to squash into more than 1 commit, or to re-arrange your code into completely different commits (e.g. if you ended up working on three different features but the commits were not consecutive).
Note: You cannot use this method if you intend to open a pull request to merge your feature branch. This method requires committing directly to master.
Switch to the master branch and make sure you are up to date:
| Ruby | |
| принципиальное различие скриптовых и “обычных” языков | |
| 3 принципа ООП | |
| реализация множественного наследования в ruby | |
| duck typing | |
| многопоточность в ruby | |
| Rails | |
| что такое MVC и зачем это нужно | |
| локига в контроллере, должна ли быть и почему | |
| синхронные и асинхронные операции — предложить варианты решения |
People
 :bowtie: |
😄 :smile: |
😆 :laughing: |
|---|---|---|
😊 :blush: |
😃 :smiley: |
:relaxed: |
😏 :smirk: |
😍 :heart_eyes: |
😘 :kissing_heart: |
😚 :kissing_closed_eyes: |
😳 :flushed: |
😌 :relieved: |
😆 :satisfied: |
😁 :grin: |
😉 :wink: |
😜 :stuck_out_tongue_winking_eye: |
😝 :stuck_out_tongue_closed_eyes: |
😀 :grinning: |
😗 :kissing: |
😙 :kissing_smiling_eyes: |
😛 :stuck_out_tongue: |
Run rails new --help to view all of the options you can pass to rails new:
$ bin/rails new --help
Usage:
rails new APP_PATH [options]
Options:
-r, [--ruby=PATH] # Path to the Ruby binary of your choice
# Default: /Users/eliot/.rbenv/versions/2.2.0/bin/ruby
#SOLID Principles with ruby examples
##SRP - Single responsibility principle A class should have only a single responsibility.
Every class should have a single responsibility, and that responsibility should be entirely encapsulated. All its services should be narrowly aligned with that responsibility, this embrace the high cohesion.
##OCP - Open/closed principle Software entities should be open for extension, but closed for modification.