simonrobb

That's correct in my experience. Galvanic corrosion was never a problem for the capacitive sensors I developed a few years back (unlike the resistive sensors linked by the parent). However you typically want them more rugged than a bare PCB for industrial settings and since the capacitive field can pass through plastic I had them in a plastic housing filled with resin. Perfectly isolated from the outside environment and hard as a rock.

Here's a prototype: https://imgur.com/9yO28CY

Unreinforced masonry is weak in tension because of the weak binding interface between the masonry unit and the mortar. The reason masonry is used in wall construction and not in, say, a suspended floor, is precisely because walls don't typically experience tensile forces. Any tensile force resulting from e.g.: wind loading on the entire structure is typically overcome by the self-weight of the masonry.

If there is a special case where tensile forces are expected, for example a retaining wall, or a mid-rise structure, or earthquake load, the engineer will specify the the masonry is reinforced with steel and then it can resist tension through the unit/mortar interface just fine.

It is a poor structural engineer who tells the architect masonry isn't an option because tension.

Link text should match the article headline; City of Sydney is a much smaller municipality than Greater Sydney, as this title suggests.

Matt Estlea is only young but he has a real talent for teaching. Fun to watch, goes pretty deep into the basics: https://www.youtube.com/channel/UCxWzA3ZlYEOLr1JkKH0ZMyg

Spectacular! Well done on shipping a product/service which I've wanted for a long time. In particular the financing option will enable me to take the leap into the world of fine art for the first time.

I mean, anecdotal data ra ra ra, but this is super appealing to me, and I'll probably be making my first art purchase >$500 as a result.

M3 provides local storage but is not experimental, on top of that with cluster replication which VictoriaMetrics does not provide, and has a kubernetes operator to help scale out a cluster.

Disclosure: I work on the TSDB underlying M3 (M3DB) at Uber. Still worth checking out though!

Are concrete crossties pre-stressed? It makes sense now I think about it, but I'm just surprised more effort than "pour concrete into a mold" goes into such an unassuming structural member.

Chronosphere (https://chronosphere.io/) was recently started by ex-Uber engineers to build a commercial ecosystem around M3. M3 is Uber's metrics platform and isn't going anywhere. M3DB (the TSDB built to support M3) is becoming fairly integral to Uber in its own right. I'd say the trajectory is positive.

Disclaimer: I work on the M3DB team.

Which is built on Mattermost.

Yes and no. I would love to use Slack over uChat, don't get me wrong, but uChat is a skin/integration of an enterprise chat app not a greenfield build.

Look familiar? https://mattermost.com/

Yeah absolutely! It's a successful project and pretty integral to Uber, I love what I do and have a lot of faith in my manager/director. I don't anticipate any reason for our situation to change.

To my mind this quarter shouldn't be used at all in this kind of discussion since its so messy. e.g.: I take your point, but that $2.56B is the culmination of over ten years of R&D compensation. It's not at all representative of the company's broader financials.

OP's inference that Uber's quarterly loss is more than double Uber's quarterly R&D costs in general shouldn't be propped up by a moment in time observation.

> So cleaning up code, making sure no sensitive info, swear words and such, documentation, lawyery stuff, icons, PR copy, blog post, basic website, wiki, and much more nitty gritty I'm glossing over.

I'm the manager of one of Uber's OSS projects, and all that the things you listed here ring true. I just know that in our case at least, OSS prep absolutely pales in comparison to the feature/operational work put in by the team.

To be clear, when I added "really" to that first sentence it was meant to communicate that there is some cost, but in the sense that it's negligible to Uber's losses, as you point out. I was responding to OP's "dubious use of resources" comment. But I can see that wasn't clear.

Of course. But compare that cost to (say) six full time engineers pumping out code for a couple of years. It's not the dominant cost by any means. Not to mention you're paying those other folks a salary regardless.

If it helps you attract better talent, well - there's a financial incentive there through increased efficiency which I'm sure on its own is more than equal to the review cost.

It doesn't really cost anything to open source something though. These are all projects which are developed for a reason: the commercial version might be prohibitively expensive at Uber scale, or not technically capable of operating at Uber scale, or just plain doesn't exist yet. At that point you can engage with the tech community and offer it as OSS (not to mention make your engineers happy), or you can keep it to yourself and eventually lose that opportunity to somebody else.

+1 Appreciate you avoiding the usual "it's just a little smartphone app"

I'm not going to try and give an exhaustive list, but as a rough explanation: things get really, really hard when you're operating at Uber scale (hundreds of thousands of riders on trip at any one time, each demanding low latency and reliability):

- Product: native clients for each side of the marketplace in each vertical (rides, eats, freight, atg, et al), maps, localization for every country with a presence (not just language, but tax, legal, hundreds of region-specific modes e.g.: tuk tuks)

- Infrastructure: hardware teams to build on-prem DCs (cloud can get very expensive at scale), software networking to deal with said low-latency traffic, storage to optimize for reliability/latency/cost, observability (metrics, logging, alerting, tracing), security, et al

- Data: insights, operational support, routing, et al

- ATG

Hope that gives a better idea.

Fact check: R&D spend for three months ending June 2019 was $3.06B. Reported loss for three months ending June 2019 was $5.24B. So, already false.

Now take away the one-time IPO expense of $3.9B, and we're not even close to being true. Further take away the $300M "IPO driver appreciation award" and you end up with a $1B loss for three months ending June 2019. In other words, the quarterly R&D spend is over three times the size of the quarterly loss.

https://investor.uber.com/news-events/news/press-release-det...

This is exactly what happened in LA toward the end of 2018. Uber tried raising fares in order to pay their drivers more, but Lyft didn't follow suit and consequentially the market shifted toward Lyft in response. Ridesharing consumers are fickle. It seems the only way for prices to be raised are a) a stable duopoly where both companies' strategy is price matching, or b) through regulation.

We have a similar minimum in Australia to the UK, and our airfares are considerably more prohibitive than the US.

I've almost finished reading "Good to Great" (an excellent read, for whoever hasn't read it already) which analyzes Nucor's company culture. Nice to hear the reality matches the analysis.

Uber | Backend Engineer | New York | VISA

We are looking for talented engineers to join the NYC Core Storage team to develop and support M3DB: our open-source distributed time-series database, designed for massive write throughput.

As a small team working on big technical challenges, we’re looking for highly capable engineers who want to grow, teach and lead others in a challenging environment. Feel free to email me at srobb{at}uber{dot}com to discuss the role, team or Uber.

More details on the position: https://www.uber.com/global/en/careers/list/50341/

And some related links for the interested:

- M3: Uber’s Open Source, Large-scale Metrics Platform for Prometheus: https://eng.uber.com/m3/

- Optimizing M3: How Uber Halved Our Metrics Ingestion Latency by (Briefly) Forking the Go Compiler: https://eng.uber.com/optimizing-m3/

- M3DB documentation: https://m3db.github.io/m3/m3db/

The sentiment of the article leaned more toward praise than any of those you enumerated.

There is value in vocalizing a guiding principle, even if it doesn't prescribe the exact way every single situation should be approached.

I think “in LA” deserves a mention in the title.

It takes a whole lot more to build a business than technical chops.

Point well made.

Nit: meeting the requirements of law isn't barely collapsing; that requirement has so many safety factors built-in because the building code has to approximate so much. The approach isn't that dissimilar from how that "anybody" you mention would build their bridge that doesn't fall down: by guessing safely.

First - architects shouldn't be lumped in with engineers in this context. It seems like there's some confusion around how far the responsibilities of an architect extend, which makes me wonder if things are different in the US? Whenever I research it seems to be the same as Australia though. Anyway, architects know as much about structural engineering as engineers know about Le Corbusier. An architect would really have to mess up to be criminally negligent.

But in response to your comment, engineers have a very clearly defined set of rules, collectively called "the code". As long as they design to them you'll be free of criminal negligence (at least during the design & development phase, things get a little murkier in construction).

More to the point, engineering for the real-world means layer upon layer of uncertainty. e.g. civil/structural engineers use materials we can't model (we use pretty-good approximations for concrete behavior) in conditions which are unknown (soil) to resist forces we can't predict (weather, earthquakes, dynamic response to loading). How does the code deal with all this uncertainty? Slap safety-factor after safety-factor onto everything. Whoever comes up with a method for more effectively dealing with this stuff will make millions.

The most obvious example being that we design structures to resist a 1-in-100 year storm. In other words, we expect a structure to be within spitting distance of failure every hundred years. But as long as you design to that standard, you're fine.

Fume events are rare as long as you define them as being above regulated threshold of contaminants in the cabin. This is fine for most people, but others (my partner included) have sensitivities to the contaminants, which trigger neurological symptoms whenever she flies, even in "safe" conditions. These days she wears a mask whenever flying and doesn't get symptoms - except the 787, where it's not necessary.

Before we worked out the issue (the risk of which really should be communicated by airlines) she was sicks for weeks after flying. And although unlikely, she once was caught in a fume event and couldn't work for months. Others on the plane were badly affected too. This is serious stuff and the 787 is great progress.