bouncing

If search metrics are a valid measure:

https://www.economist.com/graphic-detail/2018/07/26/python-i...

"Best viewed with"

I'm going to start a drinking game every time someone says that.

Actually, yeah, he probably does. His approach doesn't scale -- not at all. He bets big on individual companies. As much as Berkshire Hathaway has scaled, it's by having employees who are similarly _involved_ in the process. They aren't armchair investors -- not now and not in the past.

And no, companies don't give tours to randos. You have to do it with a lot of money on the table. Buffet isn't rags to riches; he's medium-rich to super-rich, and he got his start in much smaller businesses.

It's far more likely that the US isn't breaking up Google or Facebook because they aren't monopolies in the traditional sense, and even if they were, US anti-trust law has been neutered by decades of classical liberalism.

Warren Buffet did not make his fortune as an absentee investor playing the stock market. Not even close.

He invested one-on-one, in businesses he thoroughly understood, after a lot of research and understanding of the business. Think less scanning a spreadsheet or stock data and more CNBC's "The Profit" -- walking around a factory floor, looking through accounts receivable, talking to the assembly team, talking to customers. THEN making a decision to invest a lot of money and steer the direction of the business.

First, you need some kind of insight into the market that others don't have and can't obtain. If you're asking this question, you're not a prodigy of economics, math, or statistical analysis. Why would you be able to predict market trends better than anyone else, and especially better than the kinds of experts your competitors have?

Well, no.

For one, the most major http client library (Axios) doesn't have support for that kind of pipelining.

But also, you don't necessarily know what to pipeline until you get the first request through. Most web apps will make a REST request, look at the contents of the response, then make another REST request. Maybe you could keep the socket open through that, or you could even use websockets to bypass HTTP altogether and use jsonrpc, but still, you don't know what you need to fetch in the second round until you finish the first one, so either way you're looking at a waterfall of requests, one after another. Pipelining them would scarcely help.

What would help is having one API request that basically says, "here's who I am and here's the page the user wants. Give me everything for it." Then you're moving the controller back to the server, and leaving only the view on the client.

Framework jockey here. I spin Vue bullshit. I also sold all my crap a few years ago and started traveling full-time, mostly in South America.

Something to consider:

1. If the server render is slow, everyone notices.

2. If the client download is slow, only people on slow connections notice and only then if it's not cached.

So in other words, your CUSTOMER on a fast connection might notice #1, but probably won't notice #2.

I'm not defending unoptimized code exactly -- I'm just pointing out that if the person paying the bills doesn't notice a problem, it's far less likely to get fixed.

If it's consistently poor coding on behalf of react apps, perhaps the documentation or culture around react isn't explaining the pitfalls or encouraging good design.

> Even on a desktop PC with a fast connection, I spend so much time staring at progress bars and loading spinners as all the various bits and bobs of the interface get pulled down and rendered.

A lot of that is likely because of the way most REST APIs are laid out.

Suppose you're looking at a page that displays an invoice for an accounting system. With a traditional non-SPA app, you'd do a bunch of SQL queries and build a page from an HTML template.

With a REST API, you're doing one HTTP call per entity, at least, and then subsequent HTTP calls for aggregate entities.

When I've made SPAs before, I've often eschewed REST and just made a single Ajax call for "everything I need to display X to the user," not just out of efficiency, but also out of laziness -- it's easy to build. As long as you internally use your API only and don't publish keys for third parties, it's easy to maintain too.

There are some solutions to address the whole problem on a grander scale (GraphQL comes to mind), but overall, that's the cause of slow SPAs in my experience.

I wouldn't assume Via and city buses cost the same to run.

If the "official" answer to the last mile problem is scooters, that'll run into all kinds of resistance from people with disabilities.

Like most cities, LA's public transit system used to be a privately-owned, for profit network, mostly from Pacific Electric and Los Angeles Railway. By the 50s, those companies had shuttered most of their routes because of competition from private cars and buses, so eventually they were bought by local government and became the public transit system.

Same thing happened in Chicago. Before there was the CTA, there were private, for-profit rail roads connecting the city, owned mostly by the Chicago Rapid Transit Company.

So, if Via is unsustainable and unprofitable, and was acquired by local government, that wouldn't really be any different from how the LA Metro got started.

Electron is the new Java+Swing.

It does work on every major desktop platform. It takes a while to load, uses more RAM, and is noticeably slower. Its apps have basic native features, like system tray/indicator support, but never support them very well and break metaphors used by truly native apps.

Electron is great for having an "offering" of a native app that's really just your web app with an installer. But the experience is never great.

IIRC, he reconnected with her and asked her for forgiveness later in life. Abandoning your child and disowning them is a shitty thing to do, mind you, but he (apparently) tried to atone for that.

That's a good point.

"We haven't figured out third party app curation yet" might have been accurate, but not in Apple's style to admit.

I'm not sure there's a strong connection with Jobs' desire to limit native code execution and social good will. It's probably worth pointing out that reportedly, Jobs himself kept iOS devices away from his own children because he considered them "too addictive."

Apple's original position on third party apps was that they deserved on the web, in what would eventually become known as "progressive web app" form. That position was abandoned not just because it was a mediocre user experience, but also, it actually prevented device lock-in, which is something Jobs obviously craved.

You can argue that some apps are time-sucks, or bad for your overall well-being, and I'll be right there with you. But that has relatively little to do with whether they're shitty web apps or native code apps.

And also, the fact that smartphones do way more than originally imagined is a great thing. In most parts of the world, I can pull out my phone, tap a few characters, and a car will magically pull up where I am and take me wherever I need to go. Or bring me food. I can translate anything to anything. I know the second a flight is delayed, which lets me be more present in life. My life is assuredly better because my smartphone is turing-complete and runs third party software.

Think-o.

Also, it's hard to structure that kind of loan, since you have no idea when repayment might take place. The only comparable thing would be a student loan, where you can defer payments until you have income.

When I was a kid, my dad was deciding between two engineering jobs; one for the US Department of Commerce and another in the private sector for a big aerospace contractor.

The private sector one paid more, I remember, but my mother brought up to my dad something interesting: You're less likely to get laid off, and you'll always have more job security, with the stable paycheck provided by a government job.

It's weird to think about it, but at this point in time, the United States Government may be one of the worst major employers in the country. Two missed pay periods, unstable leadership, no yearly budget, massive deficits, constantly changing its mind.

Indeed! iMessage should get an honorable mention. Having lived outside of the US for a few years, sometimes I forget it exists, because here even people who both have iPhones use WhatsApp. iMessage deserves an honorable mention, but with some caveats. As I recall and quickly Googled:

There have been some concerns with their security:

https://www.schneier.com/blog/archives/2016/03/imessage_encr...

https://www.pandasecurity.com/mediacenter/technology/need-kn...

https://www.tomshardware.com/news/imessage-weak-encryption-m...

Additionally, iMessage doesn't have any means of out-of-band key verification, so you actually have to trust Apple to faithfully exchange keys and there's no way to verify that it's done so.

iMessage also tells you after a message is sent (via the color of a bubble) whether the recipient received it using iMessage. That's not very good assurance if, say, you're messaging a journalist in an authoritarian country. Will it go out over SMS or iMessage? You can find out, but even a little bit of doubt about that can have significant consequences.

I'm glad iMessage does do encryption like it does, but it's no replacement for Signal and WhatsApp uses libsignal for its encryption.

> if you let someone else broker the key exchange, you trust them implicitly.

Sort of.

Yes, they could serve you a MITM key, but it would be easily discoverable when you compare security codes in the client. And since the client is widely distributed on major app stores, it would be very risky to ship a compromised client.

Ultimately key exchange is a hard problem to solve. Notice that Signal doesn't do anything that much different; Signal does the key exchange and unless you verify each user's key offline, you have to trust it. Both WhatsApp and Signal have an option to display a notice when keys change, but Signal's is on by default.

Overall it's still pretty damn good. WhatsApp is perhaps the only major form of consumer communication where, by default and with no opt-out, every single chat really is fully encrypted using a widely respected protocol (libsignal). That's not nothing.

> A corporate like Facebook would never allow that unless there was an internal shift in direction.

Sure they would. Flow has nothing to do with Facebook's business strategy, or its marketing campaigns, or even its corporate strategy. I'd be surprised if anyone on VP or higher even knows what it is.

Insofar as "NIH" wins at big companies, it's when there's a business motive to promote a certain technology or FUD about what other technologies might exist.

But engineering team A deciding not to use engineering team B's tools despite working at the same company? Happens all the time.

> Do people prefer typed JavaScript over JavaScript tho?

I'd like dynamic typing but without the implicit and dubious type coercion. Like Python.

Do people typically prefer TypeScript over ES6?

Dia. https://wiki.gnome.org/Apps/Dia/

You might consider DataGrip -- it's got surprisingly good Postgres support and even does ssh tunneling quite nicely.

Coming to a stop on a motorway mid-lane is probably among the most dangerous things an autopilot system could do.

IIRC, Tesla dings occasionally if it detects no hands are on the wheel and slowly decreases speed.

I'm what you might call a lifelong Python programmer; I discovered it as a teenager in the 90s when Red Hat's install tool broke and I dug into the source code. My previous experience was with C and Basic. I saw Python 1.x and was immediately hooked.

I've learned of course other languages; some I hate (Php) some I like (Go), but I always keep coming back to Python.

To me, Python finds a pleasant equilibrium between the heft and rigidity of something like Java and the carelessness of Php or JavaScript. Most simple operations are obvious and the native types that have direct literals cover the vast majority of your needs (dicts, lists, tuples, etc).

Then you get into meta-programming. With weakrefs and metaclasses, you can write things like ORMs without the hyper-verbosity you'd get with other languages.

For me, the main downside of Python is distribution/packaging. It's gotten a lot better with WSGI, Docker, and virtualenv/pipenv, but one of the consistent struggles I've had as someone proposing a Python-based solution is installation/deployment. Back in the bad old days, I jokingly said to a colleague we should embed the entire Python interpreter inside Php somehow so we wouldn't have to walk clients through installing our webapp.

Another notable downside of Python is that while under_scores are the agreed upon standard, plenty of libraries use camelCase, which can be irritating. And over time, there have been some misnomers in package names and curious gotchas. But among languages of its age, Python is remarkable for how cleanly it has aged.