216 karma · joined December 11, 2015
This is why multi-stage builds are a thing, which the author advocates against doing.
From the GCS pricing page:
Network egress within Google Cloud applies when you move or copy data from one bucket in Cloud Storage to another or when another Google Cloud service accesses data in your bucket.
Within the same location (for example, US-EAST1 to US-EAST1 or EU to EU) -- Free
For reference most of the fees are from transferring from NA to EU and ACAP
Lesson: if you're going to use data in a given location, you need to host data in the same location.
https://en.wikipedia.org/wiki/Honorary_degree#Use_of_title_a...
Please. They're accountable to their one billion plus customers who depend on them to keep as much riff raff as possible out of the app store. They're likewise accountable to the developers who created this market.
Apple's process is imperfect. They certainly raise a lot of false negatives. The requirements are sometimes onerous and nebulous. However, the alternative is knowingly peddling hot garbage and harming their customers, partners, third-party developers, and thus, their own business.
Independently of what you read here, you saw right through this as total bullshit, right?
Right?
When will this talking point die? It's not "ongoing". There's an overwhelming majority who have adopted Python 3 and a small population of laggards.
The government is able to achieve economies of scale that the private sector can't. I think you know damn well "the government should be giving this away for free" is just a simplified way to describe the economics.
> You could argue this is for my/public good, but you didn't ask me, you didn't get a representative vote from me. In your scenario you've just decided how to spend my money.
Right, you got yours, so you're rationalizing away your part of the cost burden.
You're participating in a society. The consent is implied. If you don't like the terms of the contract, feel free to stop enjoying all the fruits of civilization.
I _hate_ this working on Java/Maven projects. Why do I need to run all the tests in order to install dependencies? The tests should have been run at _packaging_ time. I'm installing binary dependencies, why should I not trust that they have been tested?
These are fundamentally separate concerns. If you're worried about the robustness of your dependencies, review them first.
> There is no good heuristic for picking one package over the other when they occupy a similar problem space. This is mostly a cultural problem, the community's efforts are lackluster.
Stars on Github? Issues opened vs closed? Stack Overflow? The community is active in all sorts of places and it's not that hard to get a feel for the prevailing best tool for a given job. It just takes a little effort. The community's responsibility is to maintain those parts which they have created, not give you recommendations.
> virtualenv is not installed by default
python -m venv
> Semiautomatic packaging tools (e.g. pypi into rpm)
If you want to package your application and its dependencies as an OS package, that's fine. Do it as a single unit and isolate it from the rest of the system. We have venv (or pyenv if you need a different version of Python) to solve this.
I've experienced every headache there is with Python packaging. It's been bad, it is now better but still rather quirky, but it does require some domain knowledge. If you know how to use it, you will rarely experience serious problems.
Nomad isn't a cheap imitation of Kubernetes but all these components taped together are. Kubernetes is no less composable than a system built on Nomad, it just includes more functionality from day one.
If you're running containers with a orchestrator like Nomad, at some point, you'll need DNS. So you do it yourself and then you're managing Nomad and DNS. Then (we'll assume, because you're using a container orchestrator to manage multiple services) you'll need service discovery, so you write some jobs and event handlers to glue together Nomad and your DNS solution. And then, because you're a team of responsible people, you'll want to store secrets securely, so you graft in Vault. And then, you realize zero-downtime config changes would be great, so you slap Consul in there and write some sidecars or library code to handle config updates. Then metrics. Then logs. Then rolling deployments. And it continues, indefinitely, as you add features.
If you started doing this five years ago, fine. If you start doing this today, you're out of your mind. You're just doing work for the sake of "but it's composable". There's a reason why teams still build applications on frameworks like Rails and Django even though they don't need half the features--it's more important to them to get something functional up and running than it is to satisfy delicate sensibilities about only using what's needed. Kubernetes is the analogue in the world of systems and operations.
From the "The Nomad ecosystem of loosely coupled components" section:
> It integrates very well with other - completely optional - products like Consul (a key-value store) or Vault (for secrets handling).
> At trivago, we tag all services, which expose metrics, with trv-metrics. This way, Prometheus finds the services via Consul and periodically scrapes the /metrics endpoint for new data.
> The same can be done for logs by integrating Loki for example.
> Trigger a Jenkins job using a webhook and Consul watches to redeploy your Nomad job on service config changes.
shudder
> Use Ceph to add a distributed file system to Nomad.
> Use fabio for load balancing.
And the icing on the cake:
> All of this allowed us to grow our infrastructure organically without too much up-front commitment.
So if I understand correctly, the author (and his team) preferred to do all the work of integrating/testing/debugging those components, rather than using a tool that provides every single on of those features, and more, out of the box.
Kubernetes isn't a trivial lift but it's a damn sight easier than trying to roll a cheap imitation yourself.
Elaborating a bit -- the Build engine had a feature called "sector effectors" that, when triggered, would teleport the player to a completely different sector in the map. The transition was seamless and permitted interesting effects like the illusion of having stacked floors.
The designers used this feature to most profound effect in the level Lunatic Fringe. In order to complete a full circuit of the central ring room, the player had to move through a 720-degree circle to return to the entrance. It was _extremely_ confusing playing that level for the first time.
https://dukenukem.fandom.com/wiki/Lunatic_Fringe
Fabian Sanglard wrote an excellent series about the engine here: https://fabiensanglard.net/duke3d/
Definitely give poetry a shot, it's really good. In particular, I enjoy how the maintainer engages with the community and is receptive to feedback. He's pretty good about adding features to satisfy the users, rather than handwaving legitimate concerns in one-line responses.
What risk? He's already pocketed the profits. If WeWork defaults, his property management company takes the loss, possibly sells the property, and perhaps files for bankruptcy. It doesn't affect his personal finances.
"Risk" has become cognitive poison. There can be, and often is, a huge divide between _financial risk_ and _risk of grave personal consequences_.
The diagrams in the article are terrible. The only weakness in the author's argument is the poor quality of the visual aids.
Draw your own on a piece of paper with sight lines originating from the driver's position, then projected/reflected to the mirrors. You'll find there's total overlap.
It's not an exact corollary but pypy sort of fills that niche. Unfortunately, it's two major versions behind and it's not a 100% drop-in replacement.
> barring some barriers (e.g. use caching where appropriate)
Fixtures.
If you're using pyenv, it's easy to do virtualenv with the pyenv-virtualenv plugin, at which point you don't need Pipenv because it doesn't solve anything (except locking, see blow) that you can't do with requirements files. Furthermore, if you're testing under multiple versions of Python, you'd use tox to manage your test environments anyway.
_Further_ furthermore, they authors recommend _against_ use pipenv to manage dependencies for anything but development, so it's on you to have a copy of runtime dependencies isolated from Pipfile. And since you have to put your runtime requirements in setup.py anyway, there was never any way around the issue of duplicating requirements to begin with.
The one thing Pipenv does that pip and requirements files can't is lock dependencies down the entire tree... except it's abominably slow at that because it has to download dependencies and walk the entire tree. There's a debate ongoing about using pip's cache to solve the problem but there's no end in sight.
If you're really sensitive to having the entire dependency tree frozen to exact versions of you requirements, just `pip freeze` them occasionally. It's way less hassle.
Packaging in Python is far better than it was a few years ago. There's still a lot to improve but pipenv shouldn't be part of the solution.
> The article is basically marketing copy devoid of technical details.
So since you agree with OP that it's marketing, _perhaps_ it's not a stretch to suggest that it's a bit shady for the CEO of Super Cheap Cloud Product to author a marketing piece decrying the hidden costs of OMG So Expensive Cloud Products as though it's just helpful advice?
> I think a huge part of the value of HN is lowering the barrier to entry to build great companies by providing a platform to announce and promote your product / team / etc. as well as educate people with quality content. We celebrate "Launch HN" and funding events, and are going to criticize a founder for building something awesome and talking about it?
Apples and oranges. There's a big difference between "check out this thing I made" and "these products all have somewhat opaque problems _by the way I'm CEO of a competitor_".
I was crushed when they added support for protected branches but didn't include per-user permissions.
citation needed
truly, these are challenging times for spammers
Install uBlock.
I like the idea but given the obvious problems and the fact that they want four bucks a month and no trial, I'm inclined to avoid. Shame because I would use something like this.
e: seems like "how it works" is meant to link to the video
So how many have you actually worked for? "2 for 2 [out of the experiences I cherry-picked to rationalize my bias]" really doesn't support your claim that the author is overly cynical.
> The problem is not equity, the problem is picking the right startup.
If only we could predict the outcome of the lottery, we wouldn't even need startups.
Seems to me like you dodged a bullet.
> But, the last phone call was set up with the SVP who determined that I was not a good "culture fit" after 30 mins on the phone.
Why is an SVP spending 30 minutes on the phone with candidates that have already done eight interviews with the troops on the ground? You definitely dodged a bullet.