silviogutierrez

Very interesting article. But I have to ask: would taking down the system for a couple of hours be that bad?

I looked at the company, and while they seem rather large, they're not Netflix or AWS.

I imagine they need to be up for people to be able to check in, etc. But they could just block out the planned maintenance as check in times far in advance. I'm sure there's a million other edge cases but those can be thought out and weighed against the engineering effort.

Don't get me wrong, this is very cool.

But I wonder what the engineering cost was. I'd think easily in the hundreds of thousands of dollars.

Do you have a link to a reputable source? I've heard this a lot, and have a company in the nutrition space, but I haven't seen anything conclusive

Do not use a blocking modal. Ever. Gracefully insert it so the user can finish whatever they were doing, but still see your prompt. So a banner that slides in below the title, or at the bottom, etc. It is not overlaid. And can be dismissed at any time.

That way, the request for feedback itself is not a negative, jarring experience. This is what I did on https://www.joyapp.com and had very positive results.

Agreed. This is why I created a library to render JSX through Django. See it here: https://github.com/silviogutierrez/reactivated/

Both my personal blog and business run on it in production. See my profile for links.

The biggest issue was deploying it since you need python and node. Still a work in progress, and docs are severely lacking.

But I did add a single-click deploy to Heroku:

https://dashboard.heroku.com/new?template=https://github.com...

I wonder this too, given ultimately, 99% of non-static sites will need to reach out to a central database. So to render a dynamic page, your worker then has to go to the DB, no?

Curious what is the use case. You can cache stuff, as detailed in the post, but assuming you have huge variance in page contents per user, I can't see too much use. I must be missing something.

I can totally relate. The amount of times I've spent scouring the docs for the "machine name" to put into TerraForm, or vice versa, to do through the UI...

Curious in the Strict example, what happens if you arrive from another Site (so no cookie is readable) and you do something that sets a cookie?

Have you split the universes? Is there now an alternate reality of some kind? To read that second cookie, do you always have to arrive from the first site?

Couldn't just upload email/username hashes to the platform? I believe Facebook lookalike audiences work this way. I'm sure it can be automated.

That's exactly what https://github.com/silviogutierrez/reactivated does. It's a work in progress and docs are coming.

But it's the best of both worlds: Django SSR using statically typed JSX.

See for example my blog or business sites (on profile). Both SSRed by Django using React templates.

Then when the client loads, it gracefully "attaches" for dynamic interactive behavior as needed.

By far the biggest pain point is having to run node and python on the server. So I'm working on the best way to do that.

Liszt: Bénédiction de Dieu dans la solitude: https://www.youtube.com/watch?v=K03xMG7fdQ4

A great performance by Hough — a devout Catholic.

Currently one of my favorite pieces to play.

I was inspired to learn it after hearing him play it. Both the titles and the content are deeply relevant during times of coronavirus.

Especially at the height of a solitary lockdown.

Thanks for the recommendation!

I firmly agree on #1. In fact, my piano tuner is not wheelchair-bound and that was a white lie. My apologies. He was born blind.

#2: Normally I would strongly disagree. It's a NYC trope to say our subway is in shambles because pick one of: the city is old, the city is dense, the subway runs 24/7, and so on. And yet Paris, London, and other ancient subways run better and make cheaper and faster improvements.

But looking around, it seems like accessibility is very poor for London and Paris too. So you're right. They all have this in common. In fact, NYC may even be ahead[1]

However, going on a real tangent here, with the crazy amounts of money we spend or even with quantitative easing[2], I feel like we could try novel concepts like shutting down entire city blocks for months at a time and compensate everyone involved. Yes, crazy prices, but who knows?

[1] https://www.citymetric.com/transport/what-paris-metro-map-lo...

[2] Instead of propping up bonds and equities, prop up infrastructure?

That's fair, if it's cheaper including externalities.

I think that's somewhat uncharitable of a take. But fundamentally, I agree with you.

See my other comment. In this ideal, the experience for the wheelchair-bound is comparable to others. Not the current embarrassment we have in New York, for example.

You have a good point.

But I think taken to the extreme: who wouldn't prefer a private air-conditioned taxi over 100 ˚F subway platforms?

In this hypothetical: we're assuming the facilities are good enough that the experience for the disabled is within reasonable parity.

On the other hand, if it means having to go 40 blocks uptown, just to find an elevator then head back downtown, the system is inadequate and my narrative doesn't hold.

Believe me, I'm very fiscally skeptical with government spending.

Moreover, public transportation costs in the US are outrageous. Each elevator in the tens of millions for an NYC subway station. It's a racket and unacceptably corrupt.

But we can tackle both problems, and should.

Even with hyper efficient spending, there's an external benefit that is hard to measure and value beyond the cold, hard cash needed for the infrastructure vs government-paid private rides.

I've been laterally involved in frivolous ADA lawsuits for websites before, so I also understand how even noble goals can become corrupted.

A while ago — and I have no citations for this — I read it was easier to just pay for private rides for every accessible person than to make NYC and SF's public transportation accessible. Yes, in perpetuity. Considerably cheaper, too.

Why then, go through the effort? Because they should be integrated into society like all others. I firmly believe public transportation has benefits beyond efficiency.

Something about a billionaire on the 6 train next to a restaurant worker and a wheelchair-bound piano tuner[1] strikes me as poetic and noble. Whatever the costs.

[1] Headed to my place.

Great article. But I think this part may need as second look:

    If your views involve heavy-lifting calculations or long-running network calls to be done as part of the request path, it’s a great use case for using async views.

That seems true for long-running network calls (IO). But for heavy-lifting calculations? I thought that was the canonical example of situations async won't improve. CPU bound and memory bound, after all.

You absolutely can and a large majority of Manhattan car owners do. As another commenter said, you just have to respect alternate-side-parking and cleaning rules. Typically either once or twice a week.

It's such a "New York" thing, that it's a bit of a ritual: https://www.youtube.com/watch?v=6gfCNTRIJsw

Again, this should not exist.

That's because it wasn't till the 1950s that this became common: https://www.nytimes.com/1996/03/17/realestate/streetscapes-c...

A big mistake, in my opinion. If anything good can come of COVID, it's taking back this incredibly expensive real estate that we give out for free. Yes, free. No permits needed.

Temporarily, sub 1100 can work very well for losing weight. You want resistance training and very high protein to avoid muscle loss.

This is better known as the Protein-Sparing Modified Fast (PSMF). Still an intense diet — after all it's an intelligent way to crash diet.

Long-term... not such a good idea unless you are obese.

People are frustrated since home gym equipment is hard to find. And that's a valid frustration.

However, bodyweight exercises and outdoor cardio can go a long way. Even just walking.

The single most critical aspect you can control is diet. And that requires no equipment, just the right choices. WFH has thrown a big wrench into the eating habits for many.

I run a nutrition application[1], and we've seen a big uptick in sign ups and usage. Curiously, later into the pandemic. No surprise, based on articles like this: https://www.nytimes.com/2020/07/25/nyregion/coronavirus-tail...

[1] https://www.joyapp.com

I think ultimately it comes down to personalities. I'm the kind of person that likes directories and folders. And having top level files feels clunky and disorganized. Like much organization, taken to the extreme it can be a form of procrastination to avoid doing real work. Yak shaving, if you will.

But opening the root project folder to just a list of subfolders gives me a very nice first impression.

Below is my list of config files for https://www.joyapp.com (Django + NodeJS). Not a hugely complex architecture, mind you.

Some notes: .editorconfig at least tries to consolidate this for some things. And pyproject.toml could help with Python. Still, definitely jarring and something I've noticed.

    .coveragerc

    .dockerignore

    .editorconfig

    .flake8

    .gitattributes

    .gitignore

    .isort.cfg

    .prettierrc

    .shellcheckrc

    jest.config.js

    mypy.ini

    package.json

    pytest.ini

    requirements.txt

    shell.nix

    tsconfig.json

    tslint.json

    webpack.config.ts

    yarn.lock

Exactly. Every NodeJS tutorial starts with: "look how easy it is to write a server and listen on port 3000".

Yea it's easy. But why are you writing a server? That should be the least of your concerns.

You can pretty much substitute "Django" for any case where Rails is not appropriate. That is, they go hand in hand and both have similar uses.

But there are very few cases. Fewer I'd say than this article lists. Low level programming, and yes perhaps event-based systems. [1]

I find people just like rewriting their own batteries and conventions. Fun, no doubt, and a good learning experience.

I challenge any microframework / library user to surpass the productivity of a mature framework like Rails or Django. I argue nothing comes close.

And I don't mean "for the 5 second MVP". Perhaps your app won't need some of the batteries, but your app will need logging. It will need database migrations. It will need forms and inputs. It will need media uploads. It will need to send email. And so on.

Future proofing too much is an issue in the industry. YAGNI after all. But this is the opposite case. I deem it: YAEGNI. You are eventually going to need it.

[1] Django 3.1, just released yesterday, begins treating async as a first class citizen. I was initially opposed to this, given 99% of the time you don't need async. But I suppose it's nice to have and drop down to.

Just FYI, I've been using this for a while and it works very well: https://kodiakhq.com

You can self host if you want, easy on Heroku.

Plug and play.

In my opinion: nothing, and I do mean nothing, comes close to the productivity of Django + Forms + FormSets + Admin. I've tried everything under the sun[1]

The model->form and presentation layer is so intuitive and robust that I'm surprised no JS framework has rebuilt it. Too much is focused around REST instead of domain specific inputs / outputs.[2]

So yea, I've focused on making Django more React-friendly. I want to stick to it.

[1] Ok, maybe Rails comes close.

[2] https://news.ycombinator.com/item?id=21875331

Sort of, but not always.

My blog at https://www.silviogutierrez.com is React+Django strictly server side. I like JSX that much. Try loading it with JS disabled.

Same at my business site: https://www.joyapp.com.

It was a huge ordeal getting it setup (with React SSR, etc), but it's definitely doable. I've open sourced it but it sorely needs documentation (incoming):

https://github.com/silviogutierrez/reactivated

Basically, despite the tooling (not because of it), once you get going with JSX, TypeScript and the like, nothing else comes close. At least in my experience.

But again, none of the above stops me from dumping that output into a single cache key per request. It's still dynamic, just cached robustly.

Maybe I'm missing something, but ultimately, isn't this just a re-invention of a site-wide cache?

Back in the day, in Django/Drupal/any CMS, for anonymous users, you'd just dump each page into memcached with a path URL.

Then when a new anonymous visitor comes, you load it right up from – extremely fast – memory. Maybe even faster than loading from the file system? Nginx can actually ask memcached directly, even bypassing the app server.

It feels like we've gone full circle.

Neat trick. Is this any faster than pg_dump and pg_load? Note: there's plenty of optimization you can apply to pg_dump and even use pg_restore, none applied below.

Like so:

    function save_database() {
        mkdir -p /tmp/database-snapshots
        DATABASE_NAME=$PROJECT_NAME
        pg_dump -Fc "$DATABASE_NAME" >"/tmp/database-snapshots/$DATABASE_NAME.dump"
    }

    function restore_database() {
        DATABASE_NAME=$PROJECT_NAME
        DATABASE_DUMP="/tmp/database-snapshots/$DATABASE_NAME.dump"

        if [ ! -f "$DATABASE_DUMP" ]; then
            echo "No dump to restore"
            return
        else
            psql postgres -c 'SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE pid <> pg_backend_pid()'
            psql postgres -c "DROP DATABASE IF EXISTS \"$DATABASE_NAME\""
            psql postgres -c "CREATE DATABASE \"$DATABASE_NAME\""
            pg_restore -Fc -j 8 -d "$DATABASE_NAME" "$DATABASE_DUMP"
        fi
    }