I use emacs for everything, including the shell. One of the things that had often irked me, until today, was being uncomfortable entering passwords in an emacs shell. I didn’t want emacs to display the password, and I didn’t want emacs to store the password in the kill ring, with the danger of me accidentally pasting or yanking the password later. Today I found M-x send-invisible, which totally solves the problem. Just use M-x send-invisible to enter your password and it will neither be displayed nor stored in the kill ring. I knew there had to be a way to do it! (:

I recently downloaded a bunch of Lifehacker’s Top 10 Firefox extensions, and then noticed a problem: when I downloaded things, for instance Gmail attachments, my Gmail tab would go blank and I’d have to reload the page. I fixed this problem by going to Tools, Tab Mix Plus Options, and then unchecked the box labeled “Prevent blank tabs when downloading files”. I just wanted to share this fix in case anyone else was having the same problem.

Many people place a high value on honesty. Today I want to talk about the value of predictability.

Imagine two people, Lying Lester and Honest Hal. Ask Lying Lester whether he likes pistachio ice cream and he may very well lie to you, saying “Yes, I like it very much.” Ask Honest Hal and he’ll also say “Yes, I like pistachio ice cream”, but then once you go out to the store and buy some from him, he’ll take a bite and then say “Sorry, I guess I was wrong, I don’t really like it after all.”

Honesty is great. Honesty is very important. Intent matters a lot. But predictability also matters a lot. Because what do we do with an honest answer? We act on it. We make conclusions based on it, we take it into consideration when making our plans. And if the answer we get is incorrect, our plans end up falling apart regardless of the original intent of the speaker.

It’s the “He means well” effect. Many people use “He (or she) means well” as an excuse for unacceptable behaviour. His intent is good, so forgive him, because the intent is more important than the outcome. What is this teaching? What is this reinforcing? It’s crazy to hope for behaviour A while rewarding behaviour B. People will enact behaviour B instead. (A classic example of this is hope that your employees will work hard but paying them for working long hours.) “He means well” is a perfectly fine reaction to the first few mistakes, but after that, it’s no longer a useful or compassionate reaction — you’re no longer doing anyone a favour. You’re just showing the person that their intent is what matters and that their results do not matter. And when intent becomes decoupled from results, it becomes meaningless and solipsistic.

Do you know anyone like Honest Hal? Do you know anyone who always tries to be honest, but often turns out to be wrong? Do you know anyone who always means well, but whose good intent never manages to affect their behaviour?

I just bought myself a new laptop. Her name is Ezmerelda and she’s a gorgeous red.

Originally, the company was to pay for her. But as I load and unload, customize and adjust and settle in, I realize that she really needs to be mine. She’s my first big purchase after taking my life from an unhealthy situation and making it my life.

She’s power and independence and love and strength and magick and technomagick and mine.

So, how bout that? I just bought myself a new laptop. *squee*

I’m working on an organizational Ruby on Rails app, code-named “Kyeliblocks”, which is basically a to-do list organized by date. Sort of like a slimmed-down 30 boxes. One of the features of Kyeliblocks is to be able to drag bubbles (to-do items) from one block (calendar day) to another. This was my first time using Rails and script.aculo.us for drag and drop, and I ran into a problem while studying the examples and demos. All the examples, like scriptaculous’s shopping cart demo, had a small fixed number of droppables, so they didn’t need to know which droppable was the target — it was obvious from the action. So I had some code like this to make the bubbles draggable:

<% block.bubbles.each do |bubble| %>
  <div class="bubble" id=<%="bubble_#{bubble.id}"%>>
    ...
  </div>
  <%= draggable_element "bubble_#{bubble.id}", :revert => true %>
<% end %>

and then in the block view, I made the block droppable like so:

<div class="block" id=<%="block_#{block.id}"%>>
  ...
</div>
<%= drop_receiving_element "block_#{block.id}",
  :update => "kyeliblocks",
  :url => { :action => "drag_bubble" },
  :accept => "bubble"
%>

Then in drag_bubble.html.erb, my problem became evident:

I just dragged bubble #<%=params[:id].split("_")[1]%> to some block.


I had just dragged the bubble to some block, but I had no way to know what droppable I had just dragged it to! The draggable id was passed into params as :id, but the droppable id was nowhere to be found. I didn’t want to perpetrate a horrible hack like using 14 different copy-and-pasted action names for each of the 14 blocks visible on the page at any given time — the action name was the only way I could see to differentiate the target droppable.

But I was just being completely dense. That’s what every parameter other than :action is for, in the :url hash. All I needed to do was this:

<div class="block" id=<%="block_#{block.id}"%>>
  ...
</div>
<%= drop_receiving_element "block_#{block.id}",
  :update => "kyeliblocks",
  :url => { :action => "drag_bubble", :block_id => block.id },
  :accept => "bubble"
%>

(note the :block_id parameter on the :url line), and then my drag_bubble.html.erb had all the information it needed, right there in the params hash!

I just dragged bubble #<%=params[:id].split("_")[1]%>
to block #<%=params[:block_id]%>.


Now of course this was just an intermediate step for debugging — I want the action to actually do something instead of just render a template. But I still wanted to share my embarrassingly simple solution with y’all, in case some other Rails noob can save themselves a couple of hours of hair pulling. (:

I just finished reading Stumbling on Happiness, and I highly recommend it. The material it covers overlaps a lot with the Positivity topics covered in the Usual Error presentations, and it goes into a lot more detail. It’s a whole book on positivity instead of just one presentation! If you’re interested in knowing how to live a happier life, or just curious about how your brain plays tricks on you that influence your happiness, then give Stumbling on Happiness a read.