kgrin

Fun fact: it mostly does now (varies by market, but the big players have mostly adopted it). It hasn't changed much. As others have observed, the underlying reality is that the mega-acts are inherently supply-constrained, and (enough) people are in fact willing to pay those prices.

That's one advantage of this being a CFPB action and not the result of a class-action suit.

General Counsel

Not to derail to an unrelated complaint about Fi, but it's absolutely wild that if you want to do a 3-way call from your Google Pixel phone using Google Fi service, you can't do it from WiFi (or rather, if you don't turn off WiFi before you start the call, then you'll be muted).

Apparently it's a sort-of-known issue, the workaround is to turn off WiFi before starting your call (wtf?) or use another carrier.

Google, wyd?

Active Frequency | activefrequency.com | Boston (REMOTE)

We're a custom dev agency, specializing (but not exclusively) in Django. We work with a diverse roster of interesting clients, across different industries (everything from healthcare to rock'n'roll).

We've been in business for 12 years, and the company is profitable. We're currently three full-time developers, looking to add an additional developer and our first in-house full time designer to the crew.

Details: https://www.activefrequency.com/join-us

kevin _at_ activefrequency.com

Taking that at face value, I'd say that "limit drivers doing it 'for fun' in exchange for better pay/protections for drivers doing it to eke out a living" seems like a reasonable trade-off...

For a take on Epic-the-software (as opposed to Epic-the-company), Atul Gawande had a great piece in the New Yorker recently: https://www.newyorker.com/magazine/2018/11/12/why-doctors-ha...

It gets into some (though hardly all) of the issues of why EHR software is the way it is, and why (some) doctors hate it. (Among my friends who are doctors, some hate Epic, and some absolutely love it - depends on specialty, age, institution, how it's configured, etc.)

Among some interesting issues:

- As others in this thread have noted, the buyer (administrator concerned with maximizing billing) is not the user. That's the easy one that's common to a lot of enterprises.

- Epic makes it easier for medical directors to track population health and impose standard protocols of care. Individual practitioners don't always like that! I am not expert enough in those fields to say who's right, and I suspect there's not always an obviously correct answer.

- A lot of doctors dislike the underlying mechanic - being forced to actually write down everything they're doing and why - on top of sub-par UIs. The goals of the system conflict with the goals of the practitioner.

- Interoperability sucks, but it's true that standards aren't really there, and it's hard to get consensus... plus everything you put in prod needs to be back-compatible approximately forever. A lot of institutions got burned by maintaining internal software built over decades that you can't turn off because lives depend on it, and Epic/etc. are part of trying to avoid repeating that mistake.

There's more. I only have a toehold in that world now, but love to chat about it. Email in profile.

To some degree, yes - Massachusetts did that, in fact, and the plan there (that was signed, somewhat ironically, by Mitt Romney) is very very similar to the ACA.

There are a lot of details, though, that make this complicated and not necessarily viable for all states (MA is both relatively wealthy, has relatively wealthy neighboring states, and has a somewhat unusual healthcare market).

Certain Citibank cards (not all though)

I'm not on Windows, but I'm pretty sure your problem here is the "http://" - try just:

nslookup techblog.netflix.com 8.8.8.8

Here's a common scenario: you maintain more than one project, and you can't just simultaneously upgrade e.g. Django for all of them (or literally any library where an upgrade may be non-trivial).

Yes, eventually you'll (hopefully) upgrade all your projects to the newest and shiniest versions of all your dependencies, but if you need to maintain some semblance of stability, that's not always immediately possible/practical.

The feasibility of buying 292 million tickets (as you mention) is a key barrier: many lotteries (Powerball included) explicitly and deliberately require that tickets must be bought in person. So, just as a matter of time constraints, you'd need a (nontrivial) army.

Rough ballpark: 300 million combos - let's say you buy 6000 tickets/hour (which I think is actually optimistic probably by a full order of magnitude), for 25 hours a day (assume shifts and magic days), you're still looking at 2,000 person-days.

Most of these are for chronic conditions, where people are seeing their doctor on a fairly regular (once every few months) basis. And yeah, at least some patients absolutely do ask, "hey, I heard about X, is that good for me?"

There are of course also the extreme cases of specifically asking for a given prescription, but like the parent mentioned, just having a few patients persistently ask the doc about X is enough of a motivator to get the doctor to pay [marginally] more attention to the doctor-facing literature/ads/sales force.

What about http://commonmark.org?

My understanding is that PLM very much translates to useable knowledge - just for the pharma and PHM folks who mine the backend (which is how they make money). Notably, this is all quite above-board: it's not a "secretly mine people's private medical details" situation, it's "overtly mine people's private medical details in order to help find treatments for their rare disease"...

They do - ElastiCache. And as it happens, you can choose either Redis or Memcached!

I like ZP (now Gusto), I really do, but their support over time has been lacking (and it feels like it's degrading), and as a customer I'm growing increasingly concerned that they're growing too fast to keep up.

Granted - I'm a tiny account (3 employees). That said, it's frustrating that it takes weeks to get answers to questions (some simple, some less so). When I finally do get someone's attention, the resolution is generally a good one, but it just feels like they're flat-out understaffed on the support side - which is disconcerting when dealing with things like payroll, taxes, etc.

I certainly wish ZP all the best, and perhaps this expansion into new lines of business will help them hire more support staff... but a part of me feels like, "guys, get your house in order first before your start expanding."

Channeling patio11 here, but CHARGE MORE! Or, more to the point, have some ways to price-discriminate. Maybe on # of employees; maybe on features; maybe integrations or SSO or whatever.

Obviously you're not (currently) targeting Big Enterprise, but even within your present target market there's got to be a difference in how much value you're delivering for different clients... price based on that!

Global Entry is for immigration/customs, not TSA security.

The trade-off is: they do a background check and take some biometrics, and in exchange you can skip the conversation with an immigration agent where they ask you where you're been, etc. - you just answer the usual customs-form questions at a kiosk.

It's actually a pretty reasonable trade-off, and speeds the process of going through Customs - which, unlike some of the TSA stuff, is in no way unique to the US (having gone through immigration/customs in 20+ countries, I can say with some experience that the US is far from the worst...)

"Software engineering estimates and plans often fail to live up to the reality that follows. It seems to be the only engineering discipline in which this is regularly the case."

Is it though? I live in Boston, home of the notorious* Big Dig[1]. While particularly egregious, it's far from the only large-scale civil engineering project that's gone off the rails. In fact, I'd argue that until fairly recently, many more public works projects shared the "surprise factor" of software projects. I'd recommend Caro's "The Power Broker"[2] for a fascinating history of NY-area public works (among other things - great book all around), including how much of that process was about adapting the plan to new things the builders were learning along the way ("oh, turns out that soil is completely different than we planned...")

That's not to say that there aren't particular features that make software engineering its own special snowflake - as there are meaningful differences between how civil, structural, mechanical, etc. engineers operate. But spend some time in another engineering organization and you'll find it's different, but not as different as you think it is.

(And FWIW, even civil engineers sometimes follow "agile" concepts - a company I once worked for was contracted to design a highway, and even after the construction started, engineers were "embedded" with the builders to make on-the-fly adjustments based on the environmental factors they discovered throughout the process... I wish I could find their project write-up, but it was a while ago and the company has long since been gobbled up by a bigger company).

* As a (subjective) kicker, I'd add that the Big Dig, over-time and over-budget as it was, was ultimately quite worth it... much like many software projects!

[1] http://en.wikipedia.org/wiki/Big_Dig

[2] http://www.amazon.com/The-Power-Broker-Robert-Moses/dp/03947...

That sounds pretty much identical to Zencoder, encoding.com, etc.

Sounds like speech recognition, actually - I frequently get emails from a doctor who dictates most of his emails (on mobile), and they have a very similar cadence of grammatical mistakes...

YMMV of course, but iOS/Android (and Dragon/et. al.) are pretty good at recognizing words, less so entire sentences - and remember, this is 5 years ago, so adjust accordingly (unsurprisingly, consumer-grade speech recognition has improved dramatically in the past half-decade).

I kind of wonder if they're counting "Chrome" as an app, and the 8th minute is actually SMS + phone (quaint, I know). I'd believe it either way, to be sure.

And yet when they don't, people decry (accurately!) the crappiness of non-"Google Edition" phones. For years now, the only Android devices truly competitive with iPhones have been the various Nexus/Google Play Edition/etc. devices - ones where Google has taken a heavy hand and enforced a more integrated (one might say "Apple-y") experience.

Indeed, early on in Android's life, Google was much more hands-off with the OEMs, letting a thousand flowers bloom... we got fragmentation and subpar devices, developers and consumers complained, and Google set forth on tightening the reins and exerting more control such that when people buy an "Android" phone, it means a particular experience. (And of course there's nothing stopping OEMs from shipping AOSP-based devices and just not calling them Android - as in fact a number have done).

Err... what's a plausible reason passwords would be restricted to 20 chars, other than being stored in plaintext in a char(20) field?

I'm doubtful that it's a billion dollar industry. As a prior commenter noted, shippers will likely raise rates to compensate (particularly when you're a large shipper, rates tend to be negotiated anyway), or adjust policies to make refunds scarcer.

It may be a clever hack for a few early adopters, but is likely to be somewhat self-defeating if/as it grows. (Though in fairness, "shipment auditing" is a much bigger and more interesting play than refund harvesting specifically).

AWS CodePipeline and AWS CodeDeploy (both announced simultaneously I think)

Indeed it did... thanks for the sharp eye, will fix!

Thanks for the feedback/suggestions! To answer your questions:

> Are women your target audience?

Not exclusively, but they're ~50% of the population, so they're certainly a part of it!

> Why no option to import my likes from last.fm, IMDB, or something similar?

Working on it!

> How do you guys come up with your people to like?

A combination of manual curation and what's trending/etc. You can also type in a like that's not in "Likeables" in the text box at the top right, but it sounds like that's not as discoverable as it should be!

Thanks!

I'll check on those two - I think you're right that synonym support will be important.