xecutioner

While permanently null fields and large unwieldy tables are conceptually ugly, they generally don't actually cause any real inefficiency. The extra space used by null fields is not an important consideration for most systems, and the query speed will not be slower if you set up your indexes well.

And the benefits of STI are often worthwhile (database efficiency by minimizing joins, and shared code simplicity and DRYness). So if you are going to use a traditional SQL system, just learn to ignore the conceptual ugliness and use STI. Your use case is what STI was designed for.

That said, if you are not too deep in your development cycle for this project to be attached to your database system (and it sounds like you're not), and you are willing to invest some time to research/learning, you really might want to consider an alternative to SQL (there are many good ones out there). Currently the most popular alternative (and my personal favorite) is MongoDB.

MongoDB is document-based rather than schema-based. This

xecutioner

<div class="share_buttons <%='pull-right' if defined?(pull_left) && pull_left!=true%>">
  <span class='st_facebook_large' st_url=<%=request.original_url%> displayText='Facebook'></span>
  <span class='st_googleplus_large'  st_url=<%=request.original_url%>  displayText='Google +'></span>
  <span class='st_twitter_large' st_url=<%=request.original_url%> displayText='Tweet'></span>
  <span class='st_linkedin_large'st_url=<%=request.original_url%>  displayText='LinkedIn'></span>
  <span class='st_email_large' st_url=<%=request.original_url%> displayText='Email'></span>
  <span class='st_reddit_large' st_url=<%=request.original_url%> displayText='Reddit'></span>
  <!-- <span class='st_plusone_large' displayText='Google +1'></span> -->
  <%if !defined?(pull_left) %>
    <span class="share_text">If you like this article, Then perhaps share?</span>

xecutioner

# Overall file system usages. 
df -h 

# Specific file or folder

du -sh * 

xecutioner

Answer by Jim Dennis on Stack Overflow question http://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118

Your problem with Vim is that you don't grok vi.

You mention cutting with yy and complain that you almost never want to cut whole lines. In fact programmers, editing source code, very often want to work on whole lines, ranges of lines and blocks of code. However, yy is only one of many way to yank text into the anonymous copy buffer (or "register" as it's called in vi).

The "Zen" of vi is that you're speaking a language. The initial y is a verb. The statement yy is a simple statement which is, essentially, an abbreviation for 0 y$:

0 go to the beginning of this line. y yank from here (up to where?)

xecutioner

namespace :private_pub do
  desc "Start private_pub server"
  task :start do
    run "cd #{current_path};RAILS_ENV=production bundle exec rackup private_pub.ru -s thin -E production -D -P tmp/pids/private_pub.pid"
  end

  desc "Stop private_pub server"
  task :stop do
    run "cd #{current_path};if [ -f tmp/pids/private_pub.pid ] && [ -e /proc/$(cat tmp/pids/private_pub.pid) ]; then kill -9 `cat tmp/pids/private_pub.pid`; fi"
  end

xecutioner

Remove merged branch 
  git branch --merged | grep -v "\*" | grep -v master | grep -v dev | xargs -n 1 git branch -d

Git log of code snippet
  git log -S'the line from your file' -- path/to/your/file.txt

xecutioner

# 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: 

xecutioner

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.

What to expect

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.

xecutioner

[6/18/15, 2:44:59 PM] Kapil Nakhwa: s3 = AWS::S3.new
bucket = s3.buckets.create('dns-compat-bucket-name')
[6/18/15, 2:45:33 PM] Kapil Nakhwa: s3 = AWS::S3.new(
  :access_key_id => 'YOUR_ACCESS_KEY_ID',
  :secret_access_key => 'YOUR_SECRET_ACCESS_KEY')
  
  
  bucket = s3.buckets['my-bucket'] # no request made
  
  

xecutioner

#Migrate back but a specific verison only 
rake db:migrate:down VERSION=20150406100828