rcoder

Sure, they pay state income tax, but not property taxes, which are a major part of where the city and county get their funds for transit and public services.

The differences between Portland and Vancouver are particularly stark, as the lack of an urban growth boundary in Clark county (where Vancouver is located) makes real estate (and therefore property taxes) much cheaper on the Vancouver side.

When you get right down to it, my point is simply that people who like a progressive, tax-heavy city like Portland enough to spend a lot of their time there should probably be willing to pay the taxes that go along with that lifestyle. Otherwise, they're just making it that much harder on the full-time residents.

> Added bonus: If you live in Vancouver, WA (north suburbs of PDX) and work from home > (or just in WA), there's no state income tax.

Please, please, please don't suggest that more people take advantage of this loophole! The Vancouver/Portland commute has already rendered I-5 useless, and the residents on the Washington side are currently lobbying aggressively for a new 12-lane bridge (whose cost would be paid largely by Oregon) across the Columbia to ease the congestion without taking any steps (light rail, tolls, etc.) to reduce the amount of traffic.

Portland is what it is in part because residents of the city and Multnomah county are willing to pay relatively higher taxes than those in neighboring areas for a higher level of service from the city. Our transit + public services are pretty good, but the folks who drive down from Vancouver and ride the MAX through Fareless Square to shop without paying sales tax or income tax are just freeloading.

Debian only "does too much" if what you want from an OS is a simple platform on which to build your own bespoke solution. The BSD operating systems, and OpenBSD in particular, abdicate a lot more responsibility for actual system management and application deployment to the sysadmin, while Debian provides opinionated defaults (in the form of package install layouts and configuration styles) that work for most environments.

Both have their place, but for general-purpose servers, I find Debian to be a much more productive system on top of which to build solutions. For firewalls, embedded storage devices, or load balancers, on the other hand, I still reach for a recent OpenBSD install disk, because the smaller footprint and security hardening have real advantages for systems running such a limited set of services.

Here's my quick back-of-the-napkin estimate:

Given that the winning teams seemed to be running clusters of around 20-30 systems full-bore for >24 hours, the power draw would be something like 500 watts * 20 systems * 24 hours, giving us something on the order of 240 kWHr consumed per team. (Some teams may have consumed far less, but the successful ones seemed to be running many CPU or GPU cores on relatively high-spec servers.)

According to the DoE[1], the average CO2 emissions for power generation nationwide is 1.3 pounds per kWHr. Given that, we're get about 312 pounds of carbon per team. A single cross-country airline flight can produce several thousand pounds of carbon, so all told, the contest probably has a small carbon footprint than a major business sales meeting or small tech conference.

1 - http://www.eia.doe.gov/cneaf/electricity/page/co2_report/co2...

Ruby bundles Bignum and BigDecimal libraries which provide arbitrary-precision math primitives in the standard library. Python similarly provides the 'decimal' module. Most other "dynamic" languages provided at minimum bindings to the GMP library.

Basically, you seem to be considering only the fast, C-based math primitives most languages offer by default, and ignoring the more powerful options available to those who need them.

T-Mobile will sell you prepaid service at $100 per 1000 minutes/SMS messages, or pay-as-you-go for $30-40 per month without a contract. I have service for my G1 via the latter option, which costs me about $75/mo. with unlimited data and more calling minutes than I can conceivably use.

My experience has been that most carriers will happily let you sign up for some sort of prepaid service without a contract, as long as you don't expect hardware discounts.

Okay, just a few points here:

1. The Kindle is a GNU/Linux e-book reader -- it runs a Linux kernel + userland atop an ARM chipset. The only thing "proprietary" about the system is the actual GUI tools for browsing/buying/reading books, and the radio firmware (pretty much mandated by the FCC).

2. The Kindle "experience" is very much different from what you get from reading on a laptop, even when suing a very compact model like the Eee. I've been reading book-length text on LCDs for years, but the Kindle is the first device that has allowed me to totally forget that I'm not reading a printed volume. If you haven't used one for at least 15 minutes, you really haven't had a chance to evaluate it fairly.

3. Finally, Amazon has never asserted any right to so much as examine what non-Kindle-store content you have on the device, much less delete it without your permission. Conversion of content from non-Amazon sources has been a feature of the Kindle from day 1, and any documents you acquire from other sources can simply be copied by using the Kindle as a USB mass storage device.

Like any hardware/software bundle manufacturer, Amazon has the option to render a large portion of the installed base of devices less useful via over-the-air provisioning. However, like other companies possessing such power (Microsoft, for the XBox 360; Apple, for the iPhone; not to mention basically every smartphone on every carrier) they have to weigh any potential change against the risk that their customers will go elsewhere.

That assumes that it was simply an issue of royalty payments. Publishing agreements can have many more restrictions (only authorized content, limits to which markets can be served, editorial veto, etc.) that aren't just about paying $0.20/unit.

Regardless of the feasibility, I wouldn't expect Amazon to have any interest in creating a precedent of them paying to cover up for the mistakes of publishers on the Kindle store. Unlike many people, I actually think that yanking unauthorized books after download is totally reasonable, provided Amazon offers a detailed explanation of the reason.

From what I saw on the Kindle forums, the publisher of these editions (MobileReference) mostly offers $0.99 downloads of public-domain texts. There's a $10 version of 1984 still available for purchase from Amazon here:

http://www.amazon.com/Nineteen-Eighty-Four/dp/B002A9JO9W

So, it looks to me like this was a case of a publisher illegally distributing a book to which they had no license. As an analogy, think of people who buy a bootleg DVD from a flea market while traveling overseas, only to discover it won't play in their region-locked DVD player at home. Yes, it sucks that DRM prevented them from using media they thought they had bought, but they also knew perfectly well that they were getting a deal that was just a little too good to be true.

Lua embedded inside Nmap? That looks like fun:

http://nmap.org/book/nse.html

The cost to users (and especially developers) most assuredly is not simply 2x that of a single host. Planning for full replication and hot-failover from day one adds complexity, and can actually do more harm than good if your team and tools aren't fully up-to-speed on the sometimes subtle challenges surrounding replication lag, eventually-consistent stores, and STONITH.

Actually, I think that most of these tips apply equally well to the pitfalls you might hit mid-process while refactoring.

That being said, I think the basic points are obscured by the semi-random ordering. Putting the same core recommendations into (my own, entire subjective) order of importance, I'd probably present them more like this:

1. Measure twice, cut once -- be sure you really understand a piece of code before making changes

2. Don't mix bug-fixing or feature enhancements with major refactoring work (doing minor cleanup while fixing bugs is okay)

3. Don't rip out + replace anything for which you don't have tests

4. Make sure your tests cover real-world usage, not just your internal APIs

5. Recognize when you're getting bogged down, and be willing to shelve or abandon changes

6. Set a concrete goal for your refactoring pass, and stick to it -- don't try to rewrite everything in one pass

I whole-heartedly disagree. It's important to take a stand against ineffective, borderline-illegal screening processes used by employers.

People who frequent HN may not be subject to this problem as much, but in general, most of the power in an interview is concentrated at the employer's side of the table, rather than the applicant's. For them to abuse that power by prying into people's personal lives is unethical and unfair.

Hiring managers should know better, but it sometimes takes push-back from the community to help them see the issues involved. The recent change in policy in Bozeman shows that such feedback can be effective.

I wonder sometimes if Silicon Valley really counts as a hyper-specialized region. True, much of the money in the area comes from businesses that are somehow attached to computer hardware or software, but within that sector, there's an incredible amount of variety in terms of tools, technologies, and client base.

Detroit is failing not just because its economy was driven by the automotive industry -- it was also dependent on a small number of employers (basically the Big Three automakers) who failed to compete with more agile, innovative foreign competitors.

There are certainly bigger players in the SV/Bay area whose disappearance would be felt painfully (Google, Apple, Oracle, etc.), but the business culture in the area also seems fairly able to turn collapses (SGI, AltaVista, Netscape, Sun) into opportunities, or at least mitigate the damage done.

Plaintext is readable as-is, without any explicit conversion step. That being said, if you really want a code review device, you might want to look at a cheap laptop or tablet, for one basic reason: there's no direct text editing available on the Kindle, and annotations are painful to write because of the keyboard. The DX doesn't even have numbers on the main keymap, so you have to use a symbol shift to type them.

The similarities are really more between Beanstalkd and RabbitMQ, the backend message-queuing system used by Celery. Most of the interesting bits of Celery to me is in the response handling, which lets you get the result of a deferred job after the fact without the usual busywork of correlating message IDs and managing result queues.

That being said, sometimes a more bare-bones solution like talking directly to Beanstalkd or an AMQP service makes sense. This can be especially true if you're dealing with a mixed-language environment where jobs may not share a class library or easy RPC.

I suspect you'll get the same answers that usually come up when laptop recommendations are discussed here:

http://news.ycombinator.com/item?id=249579 http://news.ycombinator.com/item?id=268438 http://news.ycombinator.com/item?id=159153 http://news.ycombinator.com/item?id=197182

(etc., etc.)

To summarize: the MacBook Pro + Thinkpad T/X series machines are widely liked, with people tending to make their choice between them on whether they prefer to run OS X or something else.

You may get a smattering of other recommendations, but honestly, any other manufacturer appears to be fairly hit-or-miss, while Apple and Lenovo tend to produce solid models year after year.

My understanding is that CALEA effectively requires you to associate an identity with each active network node, so that requests for a "wiretap" could be addressed more or less in real-time, rather than after the fact. Being able to tap into hardware to observe active network streams is only one piece of the puzzle; you also have to be able to figure out which connections belong the the subject of the wiretap request, which in most cases means associating a name with an IP address.

That's exactly what I meant -- they have to have the ability to associate an identity with an IP/active network connections, which usually means recording it at the time that access is first granted. (Doing otherwise usually indicates the to subject of surveillance that they are being watched, which is generally considered undesirable by the watchers.) Noting someone's name along with their DHCP lease is very much not the same thing as recording all traffic to and from that IP.

Shame on me. Shoulda pasted the useful link, instead of the promo link in defunkt's tweet.

This is all the more critical when you consider how the usual web developer handles the complexities of chained certificate verification: namely, by disabling verification entirely, and instead trusting every upstream certificate as offered.

For example, as of Rails 2.3, ActiveResource (the default RESTful web service API client used in many Rails applications) disables all SSL verification whenever SSL is used, without so much as a configuration flag to enable it again.

Also posted here a few minutes ago: http://news.ycombinator.com/item?id=653144

This basically looks like an effort to clean up some of the warts of RubyGems, which have become especially painful in the era of the DVCS. GitHub has made forking of Ruby libraries easy, which is great for pace of development, but also causes rapid proliferation of many potentially-conflicting versions of libraries.

Rip looks like one reasonable approach to reclaiming some sanity out of all of that.

I would presume that most coffee shops have no idea that CALEA even exists. The airport question is a good one, though -- they've obviously pretty security-minded (however poorly they may implement said security), so I would assume they've found some middle ground that allows them to offer "anonymized" access.

Of course, any paid access immediately associates a name with an IP: the person on the credit card used to charge the access.

More importantly, the Federal CALEA wiretapping law basically requires any ISP (including corporations, colleges, and other organizations that provide 'net access to their community) to record the identity of anyone given access to their network so that law enforcement agencies can gain access to usage logs.

The fact that Microsoft chose to conform with the letter of this law is to be expected; rather, the fact that Google's lawyers somehow decided they didn't have to do the same is surprising, at least to me.

Have you checked out PubSubHubbub project?

http://code.google.com/p/pubsubhubbub/

It looks like there's a lot of overlap with the feature set you need, as well as the advantage of some extra documentation + testing. It's a Python WSGI app, instead of Sinatra/Rack, and the data over the wire is encoded as Atom, but there could be some useful lessons to work from at least.

If you don't set up sessions for users working with wget, curl, etc., you'll also lock out a lot of legitimate users who want a scriptable interface to your site. This goes double if you don't offer any sort of official API.

Refusing to initialize a session for non-browser UAs just invites abuse via agent masking by malicious users, while locking out innocuous and acceptable uses by your real users.

You can always test for nil explicitly. Compare:

  unless foo
    # ... foo can be false or nil to reach this branch
  end

  unless foo == false
    # ... this branch is reached unless foo == false
  end

Since terseness is considered such a cardinal virtue amongst Ruby programmers (including myself), however, this kind of issue is often ignored, and difficult to detect unless your tests explicitly check for "truthy" and "non-truthy" values in addition to the true/false literals.

Voila! I give you XMPP + threading:

http://xmpp.org/extensions/xep-0201.html (last updated Feb. of last year)

Wave is XMPP, with additional Google extensions for a variety of collaboration features. That is possible because the first letter in XMPP doesn't stand for "XML", it's the (annoying but common) "eXtensible", suggesting that domain-specific additions are not only accepted, they are encouraged.

Yeah, it looks a lot like XMPP to me, too:

  "The Google Wave Federation Protocol is an open extension to XMPP core [RFC3920] protocol..."

(From the first paragraph of the draft spec.)

Whatever your feelings about XMPP, I challenge you to point to a standardized, interoperable protocol that you think would be a better fit. It may not be ideal, but it's extensible, already supported by a large number of clients and servers, and doesn't require starting from scratch when building interoperable software.