You waste alot of space in your layout. Specific thoughts to address that:
* Trim some of the top and bottom padding off of the logo.
* Instead of having the search field inside each of the tab groups, pull it out so that it is in the upper right, just under the "logged in as" text. Search all entries when someone searches, and group the -results- in a list that can be filtered according to type. So instead of "search problems", you just search, and the results page is showing results All (5) | Problems (4) | Tests (1). This helps by pulling the actual content up in the default views, by extracting the search form to a more discrete location.
* I'd personally have a little less margins on the left and right of the site, and a little more padding in the sidebar items, but this is just nitpicky.
I like the site's concept, but didn't do anything because I hate registering. Just let me play around and then register later if I really get hooked.
The whole point of technology is to eliminate mindless, repetitive tasks like looking at a domain, comparing it to our black-list, and ignoring it. Sure, it only takes a second, but how many times do you visit hn? How many articles do you have to parse before you have wasted time?
Letting hn users specify their own domain black-lists can be implemented trivially, and saves a ton of time, in aggregate. I agree with the grand-parent post.
In this case, I think I would complete the first job first, for a couple of reasons.
1) You estimated 6 weeks, and after 5 weeks, you have about 5 weeks remaining. Your estimate was way off. You'd really be burning the company to leave at this point.
2) You're only talking about a month of work.
In addition to the options you say you've considered, you could also consider repaying/taking no compensation for the first job, in order to pursue the second. In that case, they would be out nothing, and you would be free to pursue the other work, if you thought it was more rewarding.
The article's points about evolution continuing in terms of disease prevention, ability to fight germs, etc. are understandable, as with greater population density, exposure to those things do go up.
On the other hand, every time we make a scientific advance which allows people to continue living/reproducing when they wouldn't have before, we lower the selection criteria, and it seems like this would have to slow evolution as a result, right?
$X to make website match a given layout/image in FF and IE, where X is based on your approximation of difficulty after reviewing the provided material. $Y/hour for each modification after the initial layout is complete, where $Y is 2 or 3 times what seems a reasonable rate to you.
This will do a few things:
1) Cause the customer to get their act together up front, because they would rather only pay $X.
2) Minimize your annoyance at the back and forth, because you are making what you feel like is a lot.
Mostly you want to avoid getting into the $Y/hour area, because it just sucks, mostly. Don't be afraid to set $Y to $50 or $75. You -want- it to be a deterent as much as a way of making money. Also, if you don't set that rate high, they won't value your work. If you are willing to do it for $10/hour, you are barely a step above a fast food worker, and will be treated as such. By setting a high rate, you say:
1) You know you have skills that not everyone does.
2) You value your time, which implies you will value theirs.
3) They better take requests seriously, or they will pay for it.
If you really want to work for $10 an hour, go ahead, but you are undervaluing your work, and it won't be maintainable.
(Note: My comment takes into account the current $10-$30 range the poster mentions in a comment below.)
I am guessing the assumption is that each service that allows hook specification also identifies the info it would be posting.
ie:
Enter a webhook you would like to be POSTed to when you receive a tweet. The webhook will be appended with the following url-encoded fields: sender, time, message.
Whatever URL you specify as your webhook needs to be able to handle it. The burden is on you to make sure that you integrate successfully with what is being POSTed. It is actually a pretty nice method of ensuring that a service can inter operate with a large number of other systems without the service provider having to know about them all.
I don't think the assumption is that you can just enter any old URL and it will magically work. I think the power is behind it is that it is simple enough that:
a) any service can trivially implement their end of it
b) anyone interested in extending the service can trivially implement their end of it
I'm sure someone doing part b will decide they need to take the post and form an XML message and relay it to a web-service, but it isn't really necessary.
Good luck!