#------------------------------------------------------------- | |
# 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 |
/* BASE PATH */ | |
CKEDITOR.editorConfig = function(config) { | |
config.filebrowserBrowseUrl = "/ckeditor/attachment_files"; | |
config.filebrowserFlashBrowseUrl = "/ckeditor/attachment_files"; | |
config.filebrowserFlashUploadUrl = "/ckeditor/attachment_files"; | |
config.filebrowserImageBrowseLinkUrl = "/ckeditor/pictures"; | |
config.filebrowserImageBrowseUrl = "/ckeditor/pictures"; | |
config.filebrowserImageUploadUrl = "/ckeditor/pictures"; | |
config.filebrowserUploadUrl = "/ckeditor/attachment_files"; | |
config.filebrowserParams = function() { |
https://nearbyshops.org/2017/03/06/upgrade-postgres-database-to-9-6-on-ubuntu-16-04/ |
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.
password = 'password' | |
new_hashed_password = User.new(:password => password).encrypted_password |
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
# One away same Strings | |
# given 2 strings | |
# functions is_one_away(a,b) should return TRUE if they are one edit away | |
# 3 type of operations allowed | |
# 1 - change char | |
# 2 - add char | |
# 3 - delete char | |
# | |
# example 1 | |
# a = "abcde", b = "abfde" |
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: