Attention: the list was moved to
https://github.com/dypsilon/frontend-dev-bookmarks
This page is not maintained anymore, please update your bookmarks.
# This is a skeleton for testing models including examples of validations, callbacks, | |
# scopes, instance & class methods, associations, and more. | |
# Pick and choose what you want, as all models don't NEED to be tested at this depth. | |
# | |
# I'm always eager to hear new tips & suggestions as I'm still new to testing, | |
# so if you have any, please share! | |
# | |
# @kyletcarlson | |
# | |
# This skeleton also assumes you're using the following gems: |
/*** BAD: *** | |
* Never put $scope.$apply() deep down a call stack | |
* You may end up calling the same method inside a | |
* $digest, and find yourself using $scope.$$phase | |
* or $timeout to hack around it. | |
*/ | |
setTimeout(function(){ | |
a(); | |
}) | |
elm.bind('click', function(){ |
require 'date' | |
def is_valid_date? year, month, day | |
return false if year < 2000 || year > 2999 | |
Date::valid_date?(year, month, day) | |
end | |
class Date | |
def is_valid_date_for_millenium? millenium |
FIXME: | |
WARNING: Nokogiri was built against LibXML version 2.7.3, but has dynamically loaded 2.7.8 | |
or | |
ERROR -: Incompatible library version: nokogiri.bundle requires version 11.0.0 or later, but libxml2.2.dylib provides version 10.0.0 | |
gem uninstall nokogiri libxml-ruby | |
brew update | |
brew uninstall libxml2 |
Attention: the list was moved to
https://github.com/dypsilon/frontend-dev-bookmarks
This page is not maintained anymore, please update your bookmarks.
A recursive function is a function that makes a call to itself.
To prevent infinite recursion, you need at least one branch (i.e. of an if/else statement) that does not make a recursive call. Branches without recursive calls are called base cases; branches with recursive calls are called recursive cases.
def factorial_recursive(n)
if n == 0
// based on https://gist.github.com/Potfur/5576225 & https://github.com/james2doyle/saltjs | |
// more info: https://plus.google.com/109231487156400680487/posts/63eZzzrBSb6 | |
window.$ = function(s) { | |
var c = { | |
'#': 'ById', | |
'.': 'sByClassName', | |
'@': 'sByName', | |
'=': 'sByTagName'}[s[0]]; | |
return document[c?'getElement'+c:'querySelectorAll'](s.slice(1)) | |
}; |
window.S = function(s) { | |
return document[{ | |
'#': 'getElementById', | |
'.': 'getElementsByClassName', | |
'@': 'getElementsByName', | |
'=': 'getElementsByTagName'}[s[0]] | |
|| 'querySelectorAll'](s.slice(1)) | |
}; | |
// [S('#header'), S('.container'), S('?div')] |
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.
class User < ActiveRecord::Base | |
has_many :tasks | |
def self.with_flagged_comments | |
includes(:task).merge(Task.with_flagged_comments) | |
end | |
end | |
class Task < ActiveRecord::Base | |
belongs_to :user |