What’s the proper way to treat spam/phishing mail from a friend’s compromised account?

If a friend’s email account is compromised and used to send spam or phishing emails to my gmail address, should I click “Report spam” or “Report phishing” for those emails in the gmail web interface?

I’m thinking I should, but I’m worried it will mess up my friend’s email score/reputation/whatever and make it painful for them later if they recover their compromised account.

spampersand

Then again, maybe that’s a fair consequence for letting their account get compromised. Unless of course their email provider was compromised, which would mean it wasn’t their fault (unless they chose a notoriously bad email provider).

(side note: when I notice a friend’s email account is compromised, I immediately contact them via some other means–for example: call them–and let them know)

protips: Tiny Tiny RSS on Bluehost

The Bluehost hosting account must be configured to use a recent version of PHP. After creating a subdomain, I had to delete the .htaccess file to make sure the latest version of PHP was used.

I used the periodic cron method to update my feeds. I used the “twice daily” common schedule. Here’s my command:

/usr/php/54/usr/bin/php-cli $HOME/public_html/www.example.com/tt-rss/update.php --feeds --quiet

The explicit path is required because tt-rss needs a recent version of php meant for the cli (for example, with register_argc_argv enabled).

Cloudflare might muck up the JavaScript or CSS or slow things down. I disabled it.

My Hadoop/MapReduce article in Linux Journal

I’m proud that LJ accepted my Hadoop/MapReduce article for the April 2013 issue! If you’re new to MapReduce and are interested in learning about same, this article is for you.

 

I’ll also be presenting a talk based on the article at LinuxFest Northwest 2013.

Google: Stuck on You

I require proprietary software to get through my day, but I like not being too dependent on it. With respect to that rule for myself and Google, I’ve failed.

I probably use the Internet mainly for search and email, and I need Google for both. Maps? All the time.

And there’s a doc I’d like to read now. The most important information to me is in the comments, but I can’t see the comments because this doc is “too popular”.

Google drive notice: file too popular

Dang.

See also: You Can’t Quit, I Dare You

Books: Now Alive

More and more great tech books are marked-up plain text stored in version control and render-able to ebook/HTML/PDF.

Examples:

Turns out many ideas in this approach are recycled. Heck, Knuth released TeX in 1978.

One new-ish piece is this GitHub thing. GitHub provides a social coding service based on a popular software development power tool called git. GitHub is spreading like wildfire. Sure there’s lots of code on GitHub, but lots of other stuff too. Bike paths, home-renovation projects, and all German law! Srsly. This is just fun.

Anyone seen any novels on GitHub? Cory Doctorow, are you listening? If anyone turns out a popular novel on GitHub, it’ll be you!

See also:

Web Framework Flavor of the Month

I’ve been playing with Meteor a bit lately. It’s a “kitchen sink” system for writing web apps, complete with a database (MongoDB), server-side (Node.js), and client-side stuff. It’s all JavaScript.

It’s pretty fun for little experiments. I can imagine certain kinds of websites it would be good for (web-based chat, HTML5 games, collaborative editors, and one-webpage apps — same stuff I think vanilla Node.js excels at) and some it would not (mobile, CRUD with an RDBMS). I’m wondering if it would/should work well with larger web apps.

I’m afraid of JavaScript, but I think it’s finally time for me to overcome that fear. What better way to do so than to use JavaScript everywhere (database, server, client, APIs)?!

Meteor isn’t the only game around, it’s just the one I’ve looked at.

You are NOT a Software Engineer!

I enjoyed You are NOT a Software Engineer! by Chris Aitchison. It’s a fun analogy. Writing software certainly does feel more like something roughly planned and growing organically or evolving rather than something perfectly specified and executed. And I think this is OK.

Another thing we coders often forget: we are also authors. We write code for humans (others and our future selves) to read. I want you to be stoked when you read what I write! And coding is writing.

Avoid trivial merges with github pull requests

I like a clean, boring git history. I prefer this:

* 6ca186e Someone set us up the commit
* f55bcf8 Initial commit

to this:

*   494c94e Merge pull request #1 from kormoc/pr_test
|\  
| * 6ca186e Someone set us up the commit
|/  
* f55bcf8 Initial commit

The latter includes 494c94e, a technically unnecessary commit. I call it a trivial merge, other folks call it a merge bubble.

By default, github will preserve trivial merges when you use the “Merge pull request” button.

If you don’t want these trivial commits in your history, you have to pull (fetch/merge) locally. When someone creates a pull request for you, github sends you a handy email with a command you can cut and paste to perform the merge locally.

You can merge this Pull Request by running

git pull https://github.com/kormoc/pulltest pr_test

Or view, comment on, or merge it at:

https://github.com/meonkeys/pulltest/pull/1

Recall that git pull does an implicit merge. If you merge locally and there are no conflicts, the trivial merge will be omitted.

You may miss the trivial commits because they include a reference to the pull request on github. I won’t. I might ask the patch submitter to refer to the pull request by name/link in their commit log message.

If you want to prevent anyone from pushing trivial merges, more work is required.

Update 2013-06-25

I now prefer what GitHub’s merge button does, namely: preserving the merge history for pull requests.