Lambda Calculator (Alex Reisner)

$ sqlite <db file>

$ mysql -u<user> -p <db name>

$ psql -U <user> <db name>

List Available Databases

Databases are stored in separate files, usually with a .sqlite3 or .db extension. SQLite cannot find these files for you.

db> SHOW DATABASES;

db> SELECT datname FROM pg_database;

Create a Database

$ sqlite3 <db file>

$ mysqladmin -u<user> -p create <db name>

$ createdb <db name>

Change the Current Database

Close the client and re-open with another file.

db> USE <db name>

db> \connect <db name>

List Tables in a Database

db> .schema

db> SHOW tables;

db> \dt

Display Schema for a Table

db> .schema <table>

db> DESCRIBE <table>;

db> \d <table>

Functions

Where there is more than one way to accomplish the same thing I have chosen the most generally-usable functions since that is normally what you’ll want to use for cross-database compatibility. There are some common things which SQLite cannot do out of the box, but a lot of useful functions can be added with the extension-functions. Compilation instructions are in the downloaded file. Load the extension at the SQLite prompt:

.load <compiled extension filename>

Select a Substring

SUBSTR(<string>, <start>, <length>) # length argument is optional

Find the Position of a Substring

CHARINDEX(<sta>, <haystack>) # requires extension-functions

MySQL, and PostgreSQL

POSITION(<sta> IN <haystack>)

Raise a Number to a Power

POWER(<base>, <exponent>) # requires extension-functions in SQLite

Get the Year From a Date

STRFTIME("%Y", <date>)

YEAR(<date>)

EXTRACT(YEAR FROM <date>)

If/Then/Else

MySQL provides an IF() function that many people are used to:

IF(<condition>, <then-expression>, <else-expression>)

This is convenient but not supported by other databases. It’s better to use the more widely-implemented CASE statement:

CASE WHEN <condition> THEN <expression> ELSE <expression> END

Select an Alternative to Null

This is commonly achieved in MySQL through the use of IFNULL(x, y), but the COALESCE function is equivalent in the case of two arguments, more general, and more widely implemented. It takes any number of arguments and returns the first one which is not null.

COALESCE(<value1>, <value2>, ...)

That’s all for now, though I will probably add to this list in the future. If there is anything you would like to see added, please let me know.

Vim Heresy

Alex Reisner — 2010-09-24T00:00:00-07:00

I don’t expect anyone to like this article.

Nevertheless, I feel it needs to be written.

I first used Vi about 18 years ago. I thought it was pretty weird, but it was the only text editor I knew of on Unix so I learned the basics. My main editor, however, has always been one with a “normal” GUI (EditPlus, Gedit, etc). I’ve tried, on probably eight different occasions, to make Vi/Vim/Gvim my main tool, each time learning a little more, picking up my .vimrc from where I left off, but never successfully making the switch.

Until now.

To explain briefly: I’ve tried switching to Vim so many times because no matter what editor I’ve used I’ve always needed to resort to Vim for something. Whether it’s opening very large files, doing complex regex search and replace, column selection, or various types of advanced text formatting, Vim is the only editor I’ve used that does everything I want it to. But along with Vim comes a dogmatic, somewhat macho, insistence that the only way to use it is with the alphanumeric part of the keyboard. No mouse, no arrow keys. And over and over, after a few days of giving it a good try, I would give up.

Then, a few months ago I read a great article called Everyone Who Tried to Convince Me to use Vim was Wrong. The author’s point is not that you shouldn’t use Vim, but that you shouldn’t necessarily learn it the way everyone says you should. His successful conversion happened like this: he got MacVim, installed NERDTree, used his mouse, and stayed mostly in insert mode. As the days went by he learned new commands and gradually became more productive.

If you’re a hardcore Vim user no doubt you’re leaning over to throw up in your trash can right now.

But this is how I finally made the transition too. I already knew a lot of commands. I got around with H, J, K, and L, and also W, B, and E. But moving blocks of text constitutes a significant portion of my work and I always had a hard time doing it quickly in Vim. Select/drag/drop with the mouse in a GUI editor is pretty hard to beat and this was one of the main reasons I wasn’t using Vim. When I read Yehuda Katz’s article and finally realized I was subjecting myself unnecessarily to the Vim dogma, I again loaded up Gvim and my old .vimrc and proceeded to select text with the mouse and cut and paste with d and p. It felt “wrong,” but it worked.

To be clear: I find the mouse as frustrating as anyone. To me, a mouse is good for applications like drawing programs where there is an actual two-dimensional space to navigate. There simply aren’t enough commands in most applications that aiming an arrow at a point among the hundreds of thousands of pixels on a monitor makes sense. We already have a control device with over 50 physical buttons right under our fingers that we’re all very familiar with. But the mouse is apparently less threatening to new computer users so most GUI software is intended to be used with a mouse, and if you work in any standard OS you probably have to use the mouse for some things, right?

The only thing I find more frustrating than using the mouse is moving my hand to it, and then back again to type. But here’s the thing: if your hand is already on the mouse, because you were just doing something in a web browser or some other mouse-operated program, it might be faster to keep it there. If you’re returning to Gvim with your hand on the mouse, might it not be faster to place the cursor with a click than with a sequence of keystrokes? I’m not saying you keep your hand on the mouse after that, but unless you never use the mouse at all, doesn’t Gvim/MacVim give you a pretty significant convenience over non-GUI Vim?

Don’t worry, your disgust at this idea is endorsed by O’Reilly, whose book Learning the Vi and Vim Editors includes the following:

“…some veteran Vim users (this author included!) may cringe at the thought of grafting a GUI onto their workhorse editor…”

He goes on to show that Gvim actually adds some very nice features, but why does he need this qualification? I suspect he worries about losing credibility if he doesn’t remind the reader that he’s a Vi Tough Guy. Why does Vi seem to inspire the worst kind of religious fervor, the kind that says there’s only one way to do things?

As programmers we have a tendency to defend the technology we use and attack the things we don’t. Ruby programmers tend to despise Python, and vice versa, when the languages are awfully similar. There are some superficial differences like Python’s use of significant whitespace, but in more significant ways the languages are very comparable, and the communities feed off of each other’s work. It’s always looked like a symbiotic relationship to me, but it’s one in which the majority of participants are kicking and screaming the whole time. People will also swear that one distribution of Linux is amazing while another is awful. Again, they’re all different, and certainly everyone has a favorite, but is any Linux distribution really deserving of the hatred they sometimes receive?

I think, because we work in an industry where keeping up with the latest inventions is vital to our survival, and because we depend on a large body of somewhat esoteric knowledge to stay relevant, we put pressure on ourselves to know everything. Not knowing things means such certain death in the field of computer programming that we prefer to put down things we don’t know about than admit they might be worth knowing. We’re so afraid of being non-experts that we shrink our universe down to include just what we know. And we build up what we do know. Not just its relevance and sophistication, but its complexity. And I think that’s what happens with Vim. If we let people use the arrow keys, we somehow know less. Suddenly the thing we mastered is no longer as amazing and esoteric.

This is obviously not productive. Ignoring things we don’t know only leads to stasis and eventually boredom. And telling people to burn their mouse and chop off their arrow keys only ensures that fewer people use Vim, which is not a good thing in the long run. More users means more, better plugins. And yeah, everyone has used an arrow key in Vim at least once, so that plugin you love was written by a former arrow key user. Aaahhhh! The horror! Newbies become masters. It’s amazing how that never seems to stop happening.

Anyway, I guess my point is that these rules we have for talking about Vim are insane. I often need to open a lot of files at once and keep them in logical groups so I use tabs, which is another Vim no-no. Most Vim guides either don’t mention them or recommend against using them. But why? Of all the possible methods for working with multiple files in Vim, tabs should be the most familiar to new users. Why wouldn’t we tell beginners to use them? Why is Yehuda Katz in the minority when he suggests wading into Vim gradually, rather than jumping off the high dive?

Because it makes some people feel less smart.

That just ain’t right.

Check out my constantly-evolving .vimrc.

Testing Serialized Fixtures in Rails 3

Alex Reisner — 2010-09-02T00:00:00-07:00

As you may know, you can use Rails to store serialized values in your database. ActiveRecord silently handles the conversion of values to and from YAML as objects are stored and loaded. If you have some data that you need to keep around but which you don’t ever need to perform queries on, such as raw PayPal Instant Payment Notification parameters (presumably you extract any important information into separate attributes) you can store it in a serialized hash. Let’s say you have a Payment model with an ipn_params attribute. In your model you just need a line like this:

serialize :ipn_params

and you will be able to use the attribute for storing a Ruby hash, array, or anything that can be converted to YAML. However, what do you do when you’re testing such a model using fixtures? In Rails 2 there was very convenient (though not well-documented) technique; you could do something like this, assuming params and ducks are serialized attributes (hash and array respectively):

payment1:
  date: "2010-09-02"
  params: {date: 2010-09-02, amount: 102.45, method: visa}
  ducks: [4, 5, 6, 3, 12, 97]

Note that you must include a space after each colon. However, in Rails 3, some time after 3.0.0.beta4, this stopped working. I’m not sure if there is an official alternate syntax, but I’ve been using this, which has worked so far:

payment1:
  date: "2010-09-02"
  params: <%= {
    "date" => "2010-09-02",
    "amount" => "102.45",
    "method" => "visa"}.to_yaml.inspect %>
  ducks: <%= [4, 5, 6, 3, 12, 97].to_yaml.inspect %>

If someone has a more elegant method please post it in the comments, but for now this is at least a quick fix to stop your tests from failing.

Duplicate link_to_remote With Rails 3 and UJS

Alex Reisner — 2010-07-20T00:00:00-07:00

In Railscast #205 Ryan Bates shows how to use UJS to update an element using AJAX. However, with his technique the server returns a JavaScript response: code which inserts a string into an element on the page. The problem with this approach is that the server needs to know where to insert its response (DOM ID of the target element). Most of my Rails 2 applications were designed so that each page is a “client” which receives a plain HTML response from the server and inserts the body of that response into the appropriate element on the page. This means the same server action (URL) can be used to generate content that gets inserted into different pages on the site. Not only does this make server actions simpler and more general, it makes their output easier to test.

Turning HTML into a JavaScript-escaped string on the server just doesn’t feel right.

How To Do It

Rails 3 dictates that we replace things like this:

<%= link_to_remote "more", :url => {...} %>

with things like this:

<%= link_to "more", {...}, :remote => true %>

With good old link_to_remote we could pass an :update option to achieve the system described above, in which the page receives a generic response and updates the specified element with it. But link_to doesn’t accept an :update option because with Rails 3 and UJS we want to avoid putting JavaScript in our <a> tag attributes. In Rails 3 link_to with remote="true" renders something like this:

<a href="..." data-remote="true">more...</a>

Then the Rails UJS drivers (currently available for Prototype and jQuery) look for links and forms with a data-remote="true" attribute and AJAX-ify them. So how do we do this? If we don’t write the code that makes the AJAX request, how can we access the response? The answer is: events.

The UJS drivers trigger six events on every AJAX call:

ajax:before
ajax:loading
ajax:success
ajax:failure
ajax:complete
ajax:after

You should recognize these event names from the old link_to_remote method options, and we simply need to listen for them on our AJAX-triggering elements.

Example

Let’s say we have a page that lists the ten most popular products in our database. At the end is a link to load all the remaining products via AJAX:

<ul id="products-list">
  <li>...</li>
  <li>...</li>
  <li>...</li>
  ...
</ul>
<%= link_to "more...", "/products/all",
  :id => "load-more", :remote => true %>

The server returns plain HTML and we use the ajax:x events triggered by the Rails UJS drivers (here jQuery) to grab the server’s response and insert it into the right element on the page:

<%= javascript_tag do %>
  $("#load-more").bind("ajax:complete", function(et, e){
    $("#products-list").html(e.responseText); // insert content
  });
<% end %>

If desired, we can also use the ajax:loading event to change the link text (or show a spinner):

<%= javascript_tag do %>
  $("#load-more").bind("ajax:loading", function(et, e){
    $(this).html("Loading..."); // swap link text
  });
<% end %>

Unexpected Token Error

In implementing the above solution you may receive a JavaScript error, something like this:

Uncaught SyntaxError: Unexpected token

Nathaniel Bibler explains:

Here’s the problem: if you’re building a RESTful interface in Rails, then you’ve probably got respond_tos setup for HTML and JS. So, in this case, the browser load hits /products and loads the original product list. It renders a link to AJAX load the additional products. Let’s say that action is also to /products (but for JS). So, as you’ve described in your tutorial, you’d like to just render HTML back to the client for the JS request. That’s fine, except that by default jQuery will expect that it’s executable JavaScript, since it’s making a JavaScript request (this is defined by the jQuery.ajax(:dataType)). So it’ll get the HTML string back and attempt to interpret it as javascript and blow up.

To fix that, you’d think you can just set the dataType to 'html'. Well, yes, and no. That fixes it from jQuery’s perspective. It will no longer try to execute it and you’ve now gotten past the Unexpected token issue. But, in doing so, jQuery will now make the AJAX request with an Accept: text/html header. So, Rails will now think you’re a web browser requesting the standard HTML page and will not render your JS view. So, now you’re sending back the page with full layout. To sum up, jQuery and Rails are not quite on the same page if you’re making a “javascript” request but returning “html.” It breaks things.

By the way, you can dictate the dataType to use by setting a "data-type" attribute on your remote link:

<%= link_to 'foo', '/foo', :remote => true, 'data-type' => 'html' %>

which renders:

<a href="/foo" data-remote="true" data-type="html">foo</a>

If, however, you want this functionality, I would suggest using the "text" data-type. Basically what would happen here is that jQuery will not execute the returned content. So, that fixes your first issue. Rails will still, however, attempt to render a TEXT response, since jQuery will post an Accept header with "text/plain" in it, first. As long as you don’t have a respond_to defined for "txt" (or some other "text/plain"), then Rails will continue down the Accept header string to locate an acceptable response. jQuery is smart enough to also contain an application/javascript string in there, so, eventually, Rails will decide that a JavaScript response is acceptable, and render the JS response you’re expecting. It’s very slightly hacky, but it works.

You Don't Understand Edward Tufte

Alex Reisner — 2010-04-23T00:00:00-07:00

Or at least there are a lot of people writing about data graphics right now who don’t. This is not to say that Tufte is the end-all for data graphics design, but that if you’re going to call something “Tufte-esque” you should understand what Tufte is preaching.

Tufte preaches a lot of things, actually, but I believe his philosophy can be summed up like this:

Be efficient. Show as many relationships as can be clearly read, and maximize the amount of information conveyed by every drop of ink on the page.

Of course there’s more to his philosophy, but that’s the crux of it. Tufte wants you to be concise, and remove everything that isn’t necessary. In a way he is to graphic design what Jakob Nielsen is to writing. Here are some things which have been referred to as “Tufte-esque” (not necessarily by the authors):

Tufte is not about being slick, colorful, or particularly “pretty.” His graphics are beautiful in their expressive power, not necessarily in their aesthetic appeal (though they sometimes are that as well). This is not a criticism of the above graphics, it is just to say that they are not “Tufte-esque.”

Time in Words

Alex Reisner — 2010-04-15T00:00:00-07:00

The trend during the past several years towards labels like:

2 hours ago

instead of timestamps like:

3:47pm

is something I’ve never been completely comfortable with. I think the problem the wordy labels try to solve (quick understanding of a point in time relative to the present) is real and I think they are a decent solution, but they create another problem in the process.

I experience this new problem most often on my cell phone which tells me that I received a call 1 hour ago, meaning anything from 60 to 119 minutes ago. If I was on a call with a client and I need to know how long it was for billing purposes, 1 hour ago is not good enough. Why do I get a more precise time if I look at the call log in a week when it gives up trying to use words and tells me the actual date and time the call was started?

Web sites which list user content in non-chronological order (eg: Stack Overflow) often do this too, making it hard to determine what was written first, which is vital if the content is at all conversational. Again, come back in a week and it will be 10:42am instead of 2 hours ago, but why can’t we know the exact time when it was just a few hours ago? Often that’s when you need it the most.

Unfortunately I don’t have a great alternative solution to this problem. Using a combination of the two:

2 hours ago (10:42am)

10:42am (2 hours ago)

is a obvious but inelegant (and potentially confusing) answer. In some situations colors or shading could be used to indicate the relative position of a given timestamp, for example:

08:50pm
07:02pm
06:43pm
05:33pm
04:17pm
03:30pm
02:38pm
01:35pm
12:34pm
11:05am
10:42am

But this is only applicable in situations like above where many timestamps are listed together, since we don’t have any natural associations between colors and the idea of “recentness” (though perhaps there’s a metaphor that I haven’t thought of like red for hot/recent). Text size could also be used, like this:

08:50pm
07:02pm
06:43pm
05:33pm
04:17pm
03:30pm
02:38pm
01:35pm
12:34pm
11:05am
10:42am

but it looks a little goofy. Tag clouds seem to work, but again that’s many things listed together so the visual differences become immediately apparent, if not their meaning.

If anyone has a better idea, please post a comment.

When You Disagree With Your Client

Alex Reisner — 2010-03-17T00:00:00-07:00

Another programmer was recently looking over the code for one of my clients’ web sites and remarked that I should write about a file in my Git repository called DISAGREE. Here’s a quick explanation.

What It Is

The “disagree list” (doc/DISAGREE) is a file I maintain with my for-hire projects. It’s basically a list of points on which I disagree with the client. Let’s say the client wants to add 15 new items to the web site’s main navigation bar. I say that it’s not good idea to have so many links up there and I recommend against it. Why not create a sub-navbar or a sidebar instead?

No, these all need to be in the main navigation bar at the top, very big, OK?

Fine, I relent. I do the job and I make a note in the disagree list that gets committed to the repo along with the code. The disagree list entry has a title, a date, and briefly summarizes the discussion: what the client wanted, why I disagreed, and what alternative I proposed. It also refers to dates and subjects of emails if relevant.

Why?

In the course of technical projects, there are always disagreements. Documenting them has several benefits:

It adds a dimension to the code, providing some meta-information on top of the VCS log entries. It provides good introductory material for new programmers coming on the job, and gives you something to refer to in your code comments when you’re explaining that you “wouldn’t normally do this, but…”

It helps you feel better about your work by allowing you to take a positive action (writing prose) to counteract work which feels negative.

It keeps you honest by reminding you about when you’ve been wrong, and also when you pushed too hard to support a plan or idea that just didn’t matter that much. This kind of self-reflection helps you become a better programmer, and a more valuable team member.

It helps you gently remind the client about the times you’ve been right. Being able to quickly and eloquently defend yourself gives you some extra bargaining power in future discussions about the project. If you can refer to specific instances when the client should have heeded your advice, there is a better chance that your current position will be taken seriously.

It backs you up in case something you disagreed with goes really wrong. Fortunately I have no personal experience with this, but I imagine that if a situation gets to a point where legal action is involved, having a written, dated record of your position could help.

It lets you know when to quit. On those days when you’re fed up, take a look at the disagree list. It will remind you of the kind of discussions and behavior you’ve been around. Do the arguments seem important? Interesting? When decisions are finally made, do you have as much input as you need to feel professionally satisfied? You can easily show the list to someone you trust for an outside opinion.

In my experience, disagreements are worth documenting, and the time to document them is when they arise. Since they are often emotionally charged, memory is not reliable in recalling details. To the extent that your happiness on the job depends on the way conflicts are resolved, the disagree list is important.

Sending Email From Your Web Site

Alex Reisner — 2010-03-10T00:00:00-08:00

If you’ve ever run a web site which sends email to its users you may have found yourself on the opposite end of the spam problem. That is, receiving servers think your emails are spam and refuse to accept them. If you’re sending customer invoices, order confirmations, or product download instructions, this is a serious problem. You may be tempted to use an external service for sending emails, and this may be a good solution in your case, but I would argue that any well-configured web server should be able to successfully send emails. What about the output of cron jobs? Or developer notifications when errors occur? Web servers need to communicate with us, and *nix systems are naturally inclined to do it through email. So how to we make it work?

There is a lot of advice out there on how to make sure messages are delivered properly (and if you’ve visited some of the URLs strewn about your mail server logs you may be wondering if any of it is worthwhile). Some actions you can take are very helpful. Some, like getting yourself off Comcast’s blacklist, are recipient-specific and probably not worth your time. Some are completely useless. In the following paragraphs I’ll summarize the advice that has worked for me, in roughly descending order of importance. Please note that I am not an expert on mail server admininstration, just a web developer who needs to send some emails!

1. Avoid Sending Spam

This may sound either obvious or irrelevant, but it’s really important to be familiar with the ways you could be sending spam without even knowing it.

Don’t Send Email To People Who Don’t Want It

Much spam filtering these days is done by techniques (such as Bayesian classification) which rely on users reporting received messages as spam or not-spam. If you don’t want your messages marked as spam, you should avoid sending them to people who might do so. You should also provide clear instructions for un-subscribing from your mailing list (and have an actual working un-subscribe procedure).

Configure Your MTA Properly

Before you install an MTA (Message Transfer Agent, eg: Sendmail, Postfix), make sure you’re familiar with basic configuration of the software, and the implications of running an MTA. Running an MTA is not like running a web server. You can cause real problems for yourself and others (see below). Be sure to read more than one tutorial on setting up your particular MTA, and don’t forget “obvious” things like setting the proper hostname/mailname so your messages come from the correct domain.

Don’t Be an Open Relay

An open relay is an MTA which can be used by anyone to send mail to any address. Unfortunately this is the default configuration for some MTAs. If you are an open relay it’s just a matter of time until a spammer finds you and uses your server to send thousands of emails, getting you blacklisted in the process. Repeat: you will certainly be blacklisted if you are an open relay.

Avoid Backscatter

Backscatter are bounced emails, usually that were never intended to be successfully delivered. Suppose a spammer wants to send an email to victim@poorsaps.com. If they send an email to a non-existent user on your system that appears to be from victim@poorsaps.com (forged sender address), your server will “return” that message to the victim. Clever, eh?

Easy Solution to Open Relay and Backscatter Problems

If your server’s main function is to be a web server, and it doesn’t host any user accounts that need to send email, I recommend simply rejecting non-local connections on port 25 (SMTP). I do this in Postfix with this line at the top of /etc/postfix/master.cf:

127.0.0.1:smtp   inet   n   -   n   -   -   smtpd

This ensures that you’re not even wasting CPU cycles communicating over malicious connections. If you need to accept SMTP connections, use authentication and make sure your HELO response matches your hostname.

2. Remove Your Server From Spamhaus’s Blocklists

Start by checking if you’re on Spamhaus’s blocklists. Chances are your server’s IP address is on the Policy Block List (PBL). If so, don’t get mad at Spamhaus. The PBL is a block list, not a black list, and Spamhaus isn’t telling everyone that you’re a spammer. Because most computers connected to the Internet don’t send email, all IP addresses are on the PBL by default. If you want to send email you simply get yourself de-listed (it doesn’t take long). This is a good thing. The only unfortunate part is that most people don’t know about it.

If your IP address is on the SBL or XBL you may have a problem. Before doing anything else, go back to step #1 and make sure you’re not sending spam. If you’re absolutely certain that your server is not sending spam you can try to get yourself removed from Spamhaus’s list, or contact your hosting provider for a new IP address (you may have inherited a previous customer’s problem).

3. Configure Reverse DNS Lookups

Not configuring reverse DNS is nearly equivalent in effect to being listed in Spamhaus’s PBL: many servers simply will not accept your messages. Look for reverse DNS configuration in your hosting provier’s control panel. To configure, just map your server’s IP address to your site’s domain name. Simple, yet effective.

4. Format Messages Properly

This is just common sense. There is a standard format for email (RFC 2821: Internet Message Format), so you should adhere to it. Some highlights from the RFC:

each line should be no more than 78 and must be no more than 998 characters
each line must be terminated with a CRLF
headers must contain only US-ASCII characters (ASCII 32-126 inclusive)

You should also follow W3C HTML standards if you’re sending HTML email.

5. Create SPF Records

This is an important step for delivering messages to Google accounts. An SPF record is a TXT record in your domain’s zone configuration which authorizes servers to send mail from your domain. For example, to authorize only the servers named in your A and MX records, create a TXT record with this content:

"v=spf1 a mx ~all"

Be sure to include the quotes. If you need a different configuration you can use OpenSPF’s wizard to generate the record for you. I was able to confirm that my SPF record was working by noting the following header in an email sent from my server:

Received-SPF: pass (google.com: domain of admin@domain.com designates
  xxx.xxx.xxx.xxx as permitted sender) client-ip=xxx.xxx.xxx.xxx;

and the following in some spam which appeared to be from my domain:

Received-SPF: softfail (google.com: best guess record for domain of
  transitioning spammer@alexreisner.com does not designate
  yyy.yyy.yyy.yyy as permitted sender) client-ip=yyy.yyy.yyy.yyy;

I use Google Apps for email, and I imagine that if you use a different service which doesn’t care about SPF records, you will see no such confirmation. If anyone knows of a general method for checking SPF configuration could you please explain it in a comment?

6. Send All Messages From the Same Address

Google says you should do this, presumably so that you can be more accurately followed by address-based reputation tracking mechanisms.

7. Sign Email With DomainKeys or DKIM

I haven’t actually set up my MTA with DomainKeys or DKIM, but my guess is that they will be help when delivering messages to Yahoo! accounts. Basically, they provide cryptographic verification of an email’s origin. DomainKeys and DKIM are two different standards (you only need to implement one).

8. Use ‘Precedence: bulk’ for Bulk Emails?

This one is a little confusing. Google recommends using the Precedence header while RFC 2076 recommends against it. Ostensibly setting Precedence: bulk lets recipient servers know that your email is not urgent and therefore helps the Internet operate more smoothly. You might think that this would identify your email as spam, but think about it: would a spammer really mark their messages as bulk email?

Use or not, as you see fit.

Conclusion

Sending email from a web server can be daunting, and repeated failure can be discouraging. I hope the above tips are helpful to you. You can check your status as a sender on Cisco’s SenderBase and try to move from Poor to Good. You can go from Poor to Neutral in just a few days, so don’t despair.

JavaScript Framework Translation Guide

Alex Reisner — 2010-03-05T00:00:00-08:00

You may have already chosen your favorite JavaScript framework, but if you’re working on many different sites, chances are you need to know how to use some other frameworks as well. What follows is a mini translation dictionary: instructions for accomplishing some common tasks in jQuery, Prototype, MooTools, and YUI (versions 2 and 3). This should also serve as a means for superficial comparison of the libraries.

Event Listeners

DOM Ready

$(document).ready(...);

document.observe("dom:loaded", ...);

window.addEvent("domready", ...);

YAHOO.util.Event.onDOMReady(...);

YUI().use("base", function(Y){
  Y.on("domready", ..., Y);
});

Page Fully Loaded (including images, etc)

$(window).load(...);

Event.observe(window, "load", ...);

window.addEvent("load", ...);

YAHOO.util.Event.onContentReady(...);

YUI().use("base", function(Y){
  Y.on("load", ..., window);
});

Respond to Click Event

$("#id").bind("click", function(event){...});

$("id").observe("click", function(event){...});

$("id").addEvent("click", function(event){...});

YAHOO.util.Event.addListener("id", "click", function(event){...});

YUI().use("node-base", function(Y){
  Y.on("click", function(event){...}, "#id");
});

DOM Manipulation

Note that most frameworks’ selectors return proxies (eg, a jQuery object) instead of actual DOM objects. Please see each framework’s documentation for methods of manipulating DOM elements.

Get Element By ID

$("#id")

$("id") // or $$("#id")

$("id")

YAHOO.util.Dom.get("id")

YUI().use("node", function(Y){
  Y.one("#id");
});

Get All <p>s Within an Element

$("#id p") // returns a jQuery object

$$("#id p")

$("id").getElements("p")

YAHOO.util.Dom.getChildrenBy("id", function(el){
  return el.nodeName.toLowerCase() == "p";
})

YUI().use("node", function(Y){
  Y.one("#id p");
});

Append Child Element to a Parent

$("#id").append(...);

$("id").insert(...);

$("id").inject(...);

YAHOO.util.Dom.get("id").appendChild(...);

YUI().use("node", function(Y){
  Y.one("#id").appendChild(...);
});

AJAX

GET Request With Parameters (and Handle Successful Response)

$.get("/url", {request: "params"}, function(data, status){...});

new Ajax.Request("/url", {
  method:     "get",
  parameters: {request: "params"},
  onSuccess:  function(response){...}
});

new Request({
  method:    "get",
  url:       "/url",
  data:      {request: "params"},
  onSuccess: function(text, xml){...}
});

YAHOO.util.Connect.asyncRequest("GET", "/url?with=params", {
  success: function(response){...}
});