This week I’ve been ‘spammed’ 3 times via email to vote up truly mediocre content posted onto hacker news. I think if you’re going to bother people to vote for you, you should at the very least ask them what they consider worthy of your vote.

They don’t see hacker news as a source of knowledgeable material for themselves but a media channel they can exploit. If you’re going to succumb to spamming your mailing list, you might as well do it proper and pay for crowsourced votes for the position of numbero uno.

select email, count(email) as c from users group by email having c > 1 order by c;

mysqldump -u > -p

eg.
mysqldump -u root teacherseat_dev > teacherseat.sql -p

Restore

mysql -u < -p

eg.
mysql -u root teacherseat_dev < teacherseat.sql -p

:%s/\s\+$//

But what I think you really want to do is add this to your .vimrc file.

map cw :%s/\s\+$//

Then you can just type

\cw

and it will clear all whitespace in your current file.

This is what we’re going to add

<?php echo date('Y') ?>

Your footer code will look a bit different from mine, but just open footer.php in your wordpress template, and replace the year with the line of code above, you’ll never have to update your footer again.

        <div class="footer">
          <p>
            <?php echo date('Y') ?> &copy; Monsterbox Productions
          </p>
        </div><!-- footer -->        
      </div><!-- wrapper -->
    </div><!-- container -->
  </body>
</html>

I’m building a web-app with groups. There are a bunch of links in the group, and you can star, comment thumb them up. Then there is a page that shows who has starred, commented and thumbed things. Basically like digg or reddit.

So that means I need to join three tables together:

group_shared_links
shared_links
links

It may sound dumb but I didn’t learn how to use join’s recently. Never had to, so if your in the same boat that I was in, I hope I can save you time learning how to do this with my example.

Comp dead, new one coming in at end of week, this article will be finished first week of March

So what I’ve done is added in my application.sass all my z-indexes as variables:

/* z-indexes
$z_block_area_wrap:      999999
$z_tipsy:                100000
$z_options_wrap:         99999
$z_options:              99999
$z_user_options_drop:    99998
$z_expanded:             9999
$welcome_close:          2005
$z_header_wrap:          2000
$z_item_close:           2000
$z_welcome:              1999
$z_actionables:          1999
$z_library_mass_actions: 1999
$z_drag_handle:          30
$z_name:                 20
$z_icon:                 10
$z_items_count:          30
$z_column_wrap:          10
$z_wrapper:              10
$z_loading_graphic:      10

Now I can readjust these numbers so they are more sane and from now on I’ll never be confused about what number to use for my z-indexes again.

def comment_fields(f,course,discussion,comment)
  render :partial => 'comments/fields',
    :locals => { 
      :f => f,
      :course => course,
      :discussion => discussion,
      :comment => comment }
end

In these helpers you’re typing out each variable name 3 times, once in the function definition and twice in the locals hash. Wouldn’t it be great if you only had to type the name of the variables in the definition and have the local hash generated automatically? Well we’ve created a nifty helper called locals that will do just that. It works like this:

def comment_fields(f,course,discussion,comment)
  render :partial => 'comments/fields',
    :locals => locals(binding)
end

The binding object is built-in to Ruby and allows you to access a list of variable names in the local scope. The locals helper will use this object to generate a hash of variables that you can pass to the render function.

You will need to put this function in your application_helper.rb:

def locals(helper_binding,*locals)
  options = locals.extract_options!
  result = {}
  vars = eval("local_variables",helper_binding)
  for var in vars
    result[var.to_sym] = eval("#{var}",helper_binding)
  end
  result.merge(options)
end

locals(binding) will grab all the local variables that exist at the time it’s evaluated (not just the variables that are in the function definition). You can pass a hash to locals to specify additional variables to pass.

So for example this code:

def comment_fields(f,course,discussion,comment)
  user = comment.user
  render :partial => 'comments/fields',
    :locals => locals(binding,
      :comment_count => discussion.comments.length)
end

Is the same as:

def comment_fields(f,course,discussion,comment)
  render :partial => 'comments/fields',
    :locals => { 
      :user => comment.user,
      :f => f,
      :course => course,
      :discussion => discussion,
      :comment => comment,
      :comment_count => discussion.comments.length }
end

Oh, let us not forget the solution:

"This is a test".replace(/test/,'an explosion')

The problem is when your working with multiple people on a git repos you can’t work in master otherwise when you pull changes, you’ll have a messy merge and when you push you’ll make a bunch of messy lines in your git tree, and you’ll get yelled at for making those messy lines.

I want to go through the steps with you to get your git tree to look like one straight line. Look at the model below to understand what you need to do.

Lets go through the step of adding a new feature:

Make sure we’re on master

git checkout master

Make sure our master is up-to-date

git pull

Create a new branch called new_feature

git checkout -b new_feature

Make changes and commit as much as you want

git commit

1. Now we’re ready to push our changes so lets make sure our
master is up-to-date

git checkout master
git pull

2. Lets rebase (If everything was up-to-date skip this step)

git checkout new_feature
git rebase master

3. Merge new_feature into your master

git checkout master
git merge new_feature

4. Push changes

git push

That’s all there is to it! Single clean line, nobody is yelling at you, and you can make fun of your coding friends who have never rebased before.