Townley

Personally I love poetry, if for no reason other than making publishing a breeze. If I can’t use it for some reason, I like managing virtual envs with pyenv (not to be confused with pipenv. You’re better off for having missed the controversies around that)

Oh btw virtualenv is gone now; you make envs using python -m venv myEnvName

Disclaimer that basically everything below is a personal opinion:

- MyPy is a great (fine, decent) library for typing, but even without it, the type hints in newer python versions and typing standard library are super powerful. Not “rust” levels of powerful but at least on par with typescript

- Django is still excellent and now supports async views via asgi. Outside of async, django+DRF+djoser are an excellent choice for a backend. If you really like typing and cool, smaller frameworks, Starlette and the derivative FastAPI frameworks are a lot of fun. Any of those options are great for a web app backend these days

- Gunicorn is still easier to configure. UWSGI is also still around. Both are well supported - Django run server has gotten better about reloads, but it’s still not as good as node’s offerings

- asyncio has taken a bite out of celery (heh) but celery is still common and useful for deferred tasks

- I think dockerizing the app is the way to go these days. There’s just too many odd system dependencies and python compilation differences to deploy directly to an EC2 instance. Digital Ocean’s app platform or AWS Amplify (or EBS) make deploying a container image decently easy. And if youre willing to take the plunge into Kubernetes, I find it has many python-specific advantages (eg horizontal scaling to avoid pYtHOn DOesNt sCaLE” nonsense) at the cost of a tremendous learning curve. If you do end up going for a non-containerized deployment, infrastructure as code is big now, so both terraform and ansible might be your friends

- graphQL support is bad. I think Graphene (Django) is the best you’ll find. DRF being decent is one of the reasons I generally stick to REST if I can help it

- Asyncio has come a long way but still has issues with non-async codes (eg it’s hard to make a sync request or access a DB in an async block)

- Tornado was the initial async bad boy and is still around, but again FastAPI is doing some really cool stuff in async

- For data science, pandas is pretty universal but it plays very nicely with numpy. If you haven’t kept up with Tensorflow or PyTorch, you’ll be astounded by how far ML has come

I use managed k8s, but have sympathy for the bare metal folks. Wiring servers together using kubeadm is so simple and powerful that the missing pieces of the puzzle (networking and storage, for example) feel frustratingly close.

In an ideal world, you could purchase or rent commoditized resources (compute, storage, bandwidth) and have those resources deploy your application in a standardized way. K8s is so close to that out of the gate, that having to use cloud provider's expensive and proprietary offerings feels sub-optimal.

I agree that cloud offerings are the way to go for anyone without good reasons not to (eg compliance, lack of connectivity, or full control over upgrades). But a lot of the "I prefer on prem" attitude comes from realizing that having a black box of an ingress controller on my cluster isn't the end state of how apps get deployed

One reason JS makes sense (in; for example, robotics): For all of JS’ problems, it handles async wonderfully. I can think of plenty of actions in robotics that boil down to “do these 3 things concurrently and then do thing #4 when they all complete” and Promise.all or async/await are helpful constructs to have when designing those instructions. It won’t be as performant, but the developer won’t have to worry about polling or communicating across threads/processes

That’s not a knock against assembly, or to say that the same can’t be done in C with time and skill. But in many cases, compromising performance for developer efficiency is a good call.

For me, the main place the issue above rears it’s head is in data retrieved from an API. A strongly-typed language would fail loudly and predictably if a blob of JSON didn’t match the expected format. In some situations, that’s preferable to having invalid data work it’s way through the system, or having to manually implement type checking

I’m a fan of the Runtypes library for this use case. If you design your typescript interfaces using the library (admittedly a bit magical to me) you can get runtime errors if API data doesn’t match the expected type

Agreed. Though maybe it's just a heavy lean into "This thing will drive itself in a few years"

What version do you have installed? The latest version for me is 129.0 which came out 4 days ago, and I don’t see a button after tapping the mic

If you don’t mind sharing (I imagine it only increases business) what market is this that has plentiful, cookie cutter houses being declined?

As someone in a big city, daydreaming about picking the family up to a bigger living arrangement, hearing that there are perfectly-serviceable houses being ignored sounds like a great opportunity

If you have a DB cluster running on multiple EC2 instances, you can definitely do that. There are advantages/disadvantages compared to just paying for RDS (eg managing backups, system complexity, and failover) but if you already have that expertise in-house, I can imagine a scale where there might be cost savings.

My comment was specifically discussing the challenges of keeping block storage-dependent, stateful apps within k8s (as opposed to using RDS or rolling your own HA cluster on EC2 or elsewhere). Apologies to GP if I incorrectly assumed they were discussing container volumes more broadly.

Docker volumes are great. I've also run databases in docker without issue. But they're different from kubernetes "persistent volumes" and "persistent volume claims"

The issues come when you move into high availability (specifically in a Kubernetes context). K8s may decide to move your database to a different node (server) on a whim, and suddenly your data is gone. You have to solve this by having mounted, block-level storage available to your cluster (eg AWS's EBS; the product being discussed) so you can use persistent volumes. That comes with added complexity, and usually the need to incorporate db operators into your stack.

As a result, a lot of k8s admins (myself included) choose to pay crazy amounts for RDS and S3 to avoid the complexities of persistent data.

True, but while infected with mild (or no) symptoms, they may also unknowingly spread it to university employees, townsfolk, or their parents while visiting for the weekend.

So even assuming that the personal danger is acceptable (which isn't a given; 300 deaths sounds like a horrible and avoidable tragedy to me) death figures among healthy 20-somethings don't capture the full risk of keeping a university open.

You have no reason to believe that their son wants to be there in person. The son may share their parents' safety concerns

And claiming that coronavirus poses "no danger" is simply untrue. You can claim that the danger is over-stated, but young adults can and do get COVID-19

The price was right on a PS VR, so I got one and thought briefly about playing around with VR using Unity. The ecosystem was so locked down (and becoming an official developer such a challenge) that I gave up and never looked back.

The appeal of developing in Apple's ecosystem has always been the exposure to large audiences, the (relatively decent) tooling, and the ability to creatively actualize your ideas. That last one goes away when Apple starts looking more like Sony.

I'll leave it up to lawyers to decide if this is illegal, but I know this certainly makes me less excited about developing my next iOS/OSX app

In addition to raw SQL, postgres JSON fields can be indexed with GinIndex https://docs.djangoproject.com/en/3.0/ref/contrib/postgres/i...

Data caps and throttling make it prohibitively expensive.

I’ve done it for weeks in the past, and (what I personally consider normal usage) burned through my monthly cap in a week, leaving me with large overage charges that wouldn’t be sustainable long-term. I haven’t heard of a US carrier-provided plan that’s less than several hundreds of dollars, and if there is one it’s likely unavailable in rural areas

My personal reason for caring:

Without saying that white-owned businesses have it easy (no one has it easy these days), I believe that black-owned businesses face additional, unique challenges that white-owned businesses don’t. Some of those challenges are new (eg communities of color being disproportionately impacted by COVID-19) and others have been around for much longer (ranging from black communities being historically disenfranchised to the the mental overhead of code switching when talking to the majority of the country). Taken as a whole, I feel they contribute to a reality where owning a business is harder for a person of color than a white person.

That appeals to my sense of fairness in business: someone shouldn’t have to work 10%, 20%, or 100% harder to achieve the same outcomes. I feel ill-equipped to address this unfairness systemically (volunteering my time to teach code is the only example I can think of at the moment) but letting the reality of a black-owned business’s challenges factor into my purchasing decisions feels like a valid way to tip the scales back a bit closer to equilibrium.

You’re not wrong that the project has had issues and unforced errors. I’ve felt similar disappointment at the slow progress, misleading statements, and product limitations.

But they’re one of precious few companies with a fighting chance of bringing open software to mobile. For that reason alone, they’re still on the side of the angels in my opinion.

So root for the Pinephone and PostmarketOS, and continue to hold Purism accountable. But if Purism and the Librem have an outside shot at positively contributing to the mobile landscape if given the chance, then entirely-valid criticisms of the company and product should be tempered with that chance in mind.

I was skeptical, but while I was reading the article my wife looked over my shoulder at the photo on top of the article. Unprompted, she asked "Wow, she's absolutely gorgeous. Who is she?"

We might be further along towards CGI models than I thought

Unfortunately they wouldn’t have access to the registry. But with enough determination, they could still brute force your password by returning repeatedly

I agree that the k8s ecosystem isn't quite as complex as it seems at first, but specifically running stateful apps does come pretty close to earning the bad reputation.

(Disclaimer: I've tried and failed several times to get pgsql up and running in k8s with and without operators, so that either makes me unqualified to discuss this, or perfectly qualified to discuss this)

If the operator were simple enough to be installed/uninstalled via a helm chart that Just Worked, I'd feel better about the complexity. But running a complicated, non-deterministic ansible playbook scares me. The other options (installing a pgo installer, or installing an installer to your cluster) are no better.

Also, configuring the operator is more complicated than it should be. Devs and sysadmins alike are used to `brew install postgresql-server` or `apt install postgresql-server` working just fine for 99% of use cases. I'll grant that it's not apples-to-apples since HA pgsql has never been easy, but if the sales pitch is that any superpower-less k8s admin can now run postgres, I think the manual should be shorter.

IMO that's not "incorrect" so much as it is "ambiguous about the type of encryption being referred to. Even the most spy-happy, malicious service could offer HTTPS encryption, so hearing "they do encrypt some stuff" doesn't address concerns about Zoom willfully monitoring customers

Neither does the second part about promising not to spy on a conversation; surrendering conversation metadata would be almost as bad from a privacy perspective.

Good to know; my uncertainty was mounting

Axios doesn't have a paywall, so I'm going with meta comment

True, but all code ages out, and I wouldn’t expect the average LAMP stack site to have adjusted to the REST-powered react world any better than a rails app would. When use cases change, huge parts of a code base should be rewritten (otherwise it was duplicated work to begin with)

That said: good, modular, well-developed frameworks evolve alongside their use cases. Django with DjangoRestFramework is an excellent choice for many API use cases, and the migration path is about as painless a major architectural overhaul can be.

Anyone have details on what it means that Vur 3 can “more easily target native?” Is there something about Vue that’s been keeping Vue-powered Nativescript, Ionic, or Quazar from having feature parity with React Native?

The pattern (which I employ only sometimes) is to have almost all literals defined in this way. Perhaps SELECT isn’t likely to be the word you misspell, but I’m a careless typist and make 10 typos a minute. Taking this added step helps your editor save you from yourself.

To get good documentation, you can either take a documentation expert (they exist and they're worth their weight in gold) and teach them the relevant part of the code base, or take the code author and teach them to write good docs. In my opinion, the second approach is best because the code author has the nuanced familiarity necessary to provide high-level context to an end-user.

This switch by Rust seems in line with that thinking. The Rust community, through no accidents, has incredible standards when it comes to documentation. Now that the feature teams have learned to write docs that live up to that standard (a skill as valuable as writing tests IMO) it makes sense for them to do so.

Seriously... they're serving 146M sites on their own

Any Go developers with past experience in "heavier" frameworks have thoughts on giving it a try?

I enjoy working with "batteries included" frameworks currently, and value the approach of "Here's an ORM... here's a template language... here's an auth system... use or remove them as you see fit"

I've been told that the Go standard library is fully-featured enough that it can be considered a framework in its own right, but I haven't heard how converts from the Django/Rails world feel about the completeness of that "framework"

For this particular problem, they were working on pet adoption timing prediction algorithms. The proposed solution wouldn’t work as efficiently in production as one of the other competitors. That leads to inaccurate predictions on pet adoption times, which increases costs for adoption centers, and maybe euthanasia rates among kill shelters. So animal lives would be impacted by this cheat.

More importantly, Kagggle does competitions across dozens of industries. If a culture of getting better at hiding your cheat pervades the platform, that could impact finance, transportation, and medical research. In those scenarios, lives would either be threatened or at least subject to sub-optimal systems.