HN user

_asummers

2,533 karma

https://github.com/asummers

https://twitter.com/_asummers

Posts1
Comments900
View on HN

They have a bunch of differences under the hood, particularly when you want to give perms. It makes sense, sort of, on its face, that a user can’t have teams, but why? That decision is pretty arbitrary, to me. Then in GHE, users and orgs have all sorts of fun differences when you consider things like internal/public/private and how people can interact with them; to wit, if you’re in ANY team you can see ANY internal repo in an org, but if you’re limited to just personal repos, you can see no such things.

The Cue integrated Kubernetes project I'm most excited about is KubeVela[0]. Effectively, you can create an "operator" for just the YAML bits to narrow your Kubernetes API and provide best practices via the Components and Trait overrides, and it should allow platform teams to standardize how their teams are deploying software on large Kubernetes installations.

[0] https://kubevela.io/

Elixir 1.12 5 years ago

Ooooh that didn't used to be true, from what I saw! Happy that changed. I can clean up a bunch of images on my side.

Elixir 1.12 5 years ago

DateTime was added in Elixir 1.8.0. Timex filled a vacuum for a long time, and still has a few nice convenience functions. In new codebases, I of course drop Timex, but it was very much needed until those APIs were added.

Elixir 1.12 5 years ago

Only issue here is that they don't do subpatch versions. We needed Erlang 22.3.4.1 for something, so had to build by hand.

Elixir 1.12 5 years ago

It had them. But if you did a System.get_env inside the config.exs/dev.exs/prod.exs etc it would be at compile time. Various patterns arose to do that at runtime, by using things like `{:system, "FOO", Integer}` as conventions, but it was always a bit ad hoc. If a lib saw that they would know to punt the actual reading to runtime, which is what many folks did before releases.exs, which runs at RUNTIME, so things like System.get_env work as expected.

Feel free, but it's a bad hill.

I can write my own config management, secret management, volume mounting, deployments, replica scaling, hardware affinity, antiaffinity for resilience, rollover kicking out e.g. staging if there's not enough room to schedule production workloads, and the list goes on.

I can also figure out how to install and upgrade each piece of software in my universe, across a few different languages.

Or I can just use kubernetes.

From the perspective of my developers, they tell me a few things like: "I need 4GB RAM, 2 cores, I need access to the postgres secret to talk to it, and here is my hostname" and while they can tell me many, many more things, with that little information, they can have a full application in one of several different languages in minutes.

If I were to hand roll this, it'd be held together by prayers and duct tape. And I lose out on a huge active community building tools around this. I now have istio and get cross service telemetry. For free. I can set networking rules up setting up QOS between arbitrary services, both inside my network and outside. All applied behind a single interface. There's a lot of stuff I get for free, and as my team discovers things it needs to do, I have a consistent layer to do that all behind.

I'm one guy. I don't work for Google. But my team still manages _a lot_ of services, both on application end, and things like queues, databases, etc. You can say we don't need all of that, but you'd be wrong. We arguably could use more. I can reason about my infrastructure in both the small and the large.

Then you get into the idea of transferring to other companies. If someone comes into my org, they can look at what I have and see more or less everything there is in any part of my infrastructure. It's all right there, laid out in YAML. If I were to switch companies, or even teams, it'd be the same. Having a lingua franca of common terms and ideas is super critical there. To say nothing of all the work happening in the ecosystem allowing me to help my users ship features faster to our stakeholders. Doing this in VMs would be a literal nightmare.

So, respectfully, I believe your opinion is not correct here. You personally may not need it, but it's not very long before you get to reasonable amounts of services for any project that's sufficiently complex, in my experience. And even when I have just 1 or 2 I still need many of the primitives of kubernetes.

There's a really good book describing this phenomenon called Behind Human Error. It speaks of "first stories" and "second stories" and how in analysis of incidents, it is all too common to stop at the first story and chalk it up to human error, when the system itself allowed it to take place.

The power of a notary is that someone is legally verifying the state of the document under penalty of perjury. In this case, you don't trust the party doing the verification, by definition, and there's no second party, so I don't see what this solves.

That there is an immutable log of the events is an implementation detail and could be solved with a write only DB completely independent of blockchain.

Oh Shit, Git? 6 years ago

Removing them after adding to a project is still a 6-7 step process (unless this has changed and I missed it), which makes them feel clunky to use, to me.

I agree with you and find myself in a similar situation and mindspace re: time boxing. I found having a KVM switch to have to actually "go to work" and "go to personal" was a good mental switch. And make sure you have a good chair. I was having minor back issues before I upgraded my chair with how long I was spending at the desk.

Trading firms have many positions available other than the HFT algorithms. There are teams that support those to enable desks (read: startups) to get off the ground quickly (like YC!), analysis teams for doing research for future strategies, accounting, shared service teams, as well as governance teams like risk, compliance, treasury. Depending on the team you're on, your job may be drastically different. I find myself in a role focusing on devops, developer tooling, and team automation, but others on my team focus on data ingestion, financial models on top of the data, UI development for end users. If you're a skilled programmer, there will be a role for you in a sufficiently large firm.

Zoom seeks to become the single "remote work tool", challenging Dropbox, et al. directly.

Maybe they should work on the fact I can run Zoom in screen share and just about nothing else. Just entering a call for me takes ~75% of my CPU and I beach ball regularly when screen sharing lightweight text editors doing barely more than scrolling and typing.

I'm of the opinion no one should be writing new IDEs anymore for languages and should instead be writing good language servers for the language server protocol (and it's debugging friends). The duplication of effort for each IDE + language pair is just too large.

“We did not design the product with the foresight that, in a matter of weeks, every person in the world would suddenly be working, studying, and socializing from home. We now have a much broader set of users who are utilizing our product in a myriad of unexpected ways, presenting us with challenges we did not anticipate when the platform was conceived,

I mean, sure, fine, it scaled quickly. That's not what people are mad at. We could tolerate technical issues inherent with that growth of scale. But these issues are fundamental and were issues with both 5 people and 5 billion and given that some of the choices, e.g. the installer, were deliberately designed, that statement holds no water with me.

In praise of S3 6 years ago

"All time" colloquially never implies that it will be the best forever. Being all time at a specific point puts you in the running, but when talking about bands, sport teams, tech, whatever, does not discount the possibility of improvement in the future.