nfm

What's the real issue? Is it that the original coder refuses any comments, or that the OP is a particularly liberal commenter?

In either case, I don't think a technical solution will solve the actual problem. This falls into the same basket as naming conventions, tabs vs spaces, and commit message conventions: You need to figure out something that works for the team.

"UPDATE: Turns out that the notifications/share button doesn’t really work like it’s supposed to on Opera. So Google was just hiding it (till they got it to work?) so people don’t wonder why it doesn’t work. Sorry! Really should have checked if it’s working before posting this. D’oh!"

It assumes you're using git, supports multiple stages out of the box, uses a reset strategy by default instead of having to hack it in etc.

I'm planning on playing with it today.

Finish the sentence please.

NewRelic is a great tool to help you do this.

Common performance problems to look out for in Rails are:

* Missing database indexes

* Long running code (eg PDF generation, file uploads to a third party) that should be put in a job queue

* Innocent looking ActiveRecord calls that use N+1 queries or fetch way too much from the DB and the result set is further reduced in Ruby

The cost (time, money, etc) of setting up their own website and processing their own transactions is obviously prohibitive, as most nonprofits don't accept online donations.

Lots of nonprofits also know exactly what percentages of their revenue go towards administration and marketing, so they're likely to have a good comparison point for how much it costs them to receive donations by other means.

The best powerful tools don't require an in-depth understanding of them to get started (think git, rails or Linux). But mastering them over time will make you better by orders of magnitude than the copy-pasters with no fundamental knowledge of the tools they use every day.

The trick is in figuring out which tools are good, and which of them you want to commit to.

I wonder how long it will take for touch become mainstream in the laptop market.

If you're new to 3.1, the following resources will help you to get started:

Release notes:

http://guides.rubyonrails.org/3_1_release_notes.html

Asset pipeline:

http://guides.rubyonrails.org/asset_pipeline.html

http://railscasts.com/episodes/279-understanding-the-asset-p...

The best leads are always referrals. After finishing a job, make sure your client knows that you're looking for more work. If you did a good job for them they will send leads your way. This takes time to build momentum but it attracts the right kinds of customers, and your conversion rate will be way higher than for cold leads.

Good luck!

There are subtle differences between SQLite and MySQL/Postgres. You should use the same database in dev, test and production.

I'm all for keeping SQLite as the default database for development - it lowers the barrier for entry to Rails.

But for any app that you hope will someday get real traffic, using MySQL or Postgres in production is sensible and easy.

[1] http://www.sqlite.org/lockingv3.html

Almost the entire page is duplicated within a `<!--[if lt IE 9]>` block...

"While our universities are turning out very able graduates, well versed in the sexy new languages of Java, .Net and the like..."

I chuckled.

That's a pretty bold claim, particularly given the subset of features you listed!

I'm a bit paranoid though - most compromises aren't targeted and if a hacker gets a list of 20,000 hashes to crack they aren't going to inspect them individually.

Perhaps it would be better to have a more obscure suffix for Tier 1 passwords. Otherwise, if a password is compromised, a motivated attacker wouldn't have much trouble guessing your other Tier 1 passwords.

"wheatgrass makes octagrams in paypal" leads trivially to "wheatgrass makes octagrams in gmail" and "wheatgrass makes octagrams in #{bank_of_choice}".

eg: % Firefox 7 memory

Otherwise I got "Coupon 'agileweek' has expired."

I think it's simple, I like the fact that it does just one thing, and I enjoyed the geekiness of the extra encodings (binary, long and hex).

Almost every other network tool website is 50% google ads, 50% reverse-dns-propagation-zone-transfer style, with the actual IP address in small or medium size text. Double click selection works well in my browser too (FF 5.0).

You have my upvote!

Always take a part payment up front before starting work. Between 30% and 50% is a fairly standard and safe amount. Always take another part payment after demonstrating your progress. Ideally upon final delivery the balance to be paid for your work should be less than 30%.

If clients are unhappy about paying you up front, you need to ask yourself why they're unwilling to pay anything to start, when they will be paying $10k to you in the very near future.

If they don't trust you, they'll work with someone else. You need to be able to trust them too, and taking a part payment up front is often the quickest way for you to learn that they are trustworthy.

When a client isn't able to pay, you should try and negotiate payment in full over time. Regular, small payments give them a chance to pay off their other creditors and give you regular indication that they're trying to pay you back.

If they refuse to pay, or miss their regular repayments, don't be afraid to go to a debt collector. Make this clear when you are negotiating the payment schedule. At this stage, any money you can get back (less the often expensive debt collection fees) is a bonus.

Even if the amount is paid back in full, we make it a rule not to work for this client again.

For an amount this large, you should definitely talk to a lawyer. Keep a close eye on your cashflow over the next few months.

Best of luck recovering the payment!