MikeCodeAwesome

I've used JungleDisk, CrashPlan, and now Arq.

I left JungleDisk because it went sideways and S3 was too expensive. After that was CrashPlan; I liked its free remote backup option. But then my backup destination disappeared behind carrier grade NAT. That left me with paying for regular CrashPlan or looking elsewhere. Enter Arq.

Based on my estimated usage, for two computers, I calculated the following estimated yearly cost.

   JungleDisk S3 $288
   CrashPlan     $120
   Arq Glacier   $ 32

Assuming I didn't screw up my estimate, Glacier was a no-brainer, even with up-front cost of two Arq licenses ($70).

This month is the first full month in which I'm not seeding my initial Arq backup to Glacier. I'm hopeful that the cost will be significantly lower than CrashPlan.

Two guesses: cellular location services and custom radio telemetry systems. Maybe that's one guess.

Following the same procedure, you can also choose not to display your endorsements in one shot: rather than click "Manage Endorsements" instead click the down-arrow next to "Display your endorsements" and choose "No, do not show my endorsements."

Homejoy also got a writeup at AZ Tech Beat when they "launched" in Phoenix last month http://aztechbeat.com/2013/07/homejoy-an-online-booking-home....

I, too, switched to the RT-N16 after my WRT54GL died unceremoniously one day. The RT-N16 is a pretty good router but I want to caution any one who, like me, was awestruck by its 128MB RAM without considering NVRAM.

The short version is that, depending on your usage, you may run out of NVRAM before RAM and may lose your settings. For reference see [1] and [2].

[1] http://www.dd-wrt.com/wiki/index.php/Asus_RT-N16#Current_Kno... [2] http://www.dd-wrt.com/phpBB2/viewtopic.php?p=506126

Yet another fun use of watch, one of my favorite tools! I use it daily in combination with curl and grep to look for certain output of my JSON/XML services during development. The -d flag is especially useful in this regard.

  watch -d -n 5 "curl -s localhost:8080/some/service | grep status"

Along the same lines as the original post, I also use watch as an ad hoc, pseudo continuous integration tool for executing code that doesn't fit well within a REPL. [1]

[1] http://codeaweso.me/2012/09/using-watch-as-quick-continuous-...

Same here; and love that it doesn't clear the command line you're currently typing.

Does anyone know if there's a key command for clearing the scroll buffer?

I kind of hate to say this but I'm glad there's at least one other person out there who has troubles with TeamViewer on Linux. My remote coworker uses Ubuntu with two screens and we're unable to make the mouse work on the correct screen consistently. That and the screen won't update properly.

I wasn't aware of this, but mildweed posted later that PDO is coming. http://news.ycombinator.com/item?id=4907099

As the article surmised, one of the engines did indeed fail and the craft corrected for the failure.

"Falcon 9 detected an anomaly on one of the nine engines and shut it down. As designed, the flight computer then recomputed a new ascent profile in realtime to reach the target orbit…"

http://www.parabolicarc.com/2012/10/07/falcon-9-suffers-engi...

Here's one more: Michael Chiklis in The Shield.

Checks are frequently turned into ACH transactions. You may be interested in http://www.occ.gov/topics/consumer-protection/depository-ser....

Given your scenario, you are indeed correct: throwing implementation-specific exceptions leaks internal details and further couples clients of the API. Can you imagine using such an API which forces you to continually handle new exceptions that arise from new implementations? As you suggest, it's better to create an exception for the API which then wraps the underlying exception. I would not go so far as to create a family or hierarchy of API exceptions unless there's a need to communicate each of them individually.

What usually happens in practice is a combination of none and all the above. A bit of a mess, really.

My team consists of four people, two of which are remote, spread across three adjacent timezones. We find that a regular three-way conference call is sufficient. This arrangement has worked well for three years.

The idea of using Skype has surfaced once or twice but we've gotten by without it. I doubt we'll ever need it.

As for advice…

* I would suggest everyone place their call from a suitably quiet room. Someone doing dishes, making tea, or wrestling with a dog is extremely distracting.

* Hold the standup meeting on time and don't delay more than five minutes. If you don't, you're effectively chaining people to their phones for an indefinite amount of time.

* Two or more people in a room together should remember to speak to the phone and not each other. It's amazing how much of a statement or conversation can be lost over the phone when co-located people use gestures and glances to communicate.

I have a fondness for geography and maps, so I am delighted to see this posted here. Big Think covered this back in February, 2011: http://bigthink.com/strange-maps/502-hung-out-to-dry-a-taxon....

The above article is part of Big Think's Strange Maps, a fantastic blog which has many, many more interesting articles!

> Based on this, I will boldly make the following prediction: in 10 years' time, the most popular languages will still be some variant of Java and C#.

Your conclusion may very well come to pass. This reminds me of another article, Beating the Averages, in which pg writes: "And so the median language, meaning whatever language the median programmer uses, moves as slow as an iceberg."

http://www.paulgraham.com/avg.html

The Executive Veto power serves this purpose. Every new law may reviewed and rejected by the President. http://en.wikipedia.org/wiki/Executive_veto#United_States

I'm unaware of a specific name, but it's not a new idea. See The Moon is a Harsh Mistress by Robert Heinlein. (link to Google Books reference http://goo.gl/IdBoU)

Indeed. According to the August, 2012 print edition of Popular Science, there are 500,000 people being transported in air at any given moment.