Which is still horrifically slow and unoptimized. I’m not sure why streaming tokens from an api into an electron app is difficult but OpenAI managed to bungle it somehow.
You’ll hear various opinions on how good it is at each of these roles. In my personal experience it is a decent package manager, a poor but serviceable templating engine, and a horrifically bad deployment tool.
Normally you pair Helm with something like Flux or Argo if you want IaC
IMO terraform is probably not the right tool for the job for managing deployments. It can do it, but like helm itself, it’s also not super great at doing cluster deployments. If you’re looking for a good GUI like experience Argo is a good option.
I like Terraform for managing infra, and it’s good at a lot of things, but managing deployments on a cluster with IaC is not one of them. Why? Mainly because deployments are much more dynamic than infrastructure and the amount of throat clearing required for terraform to perform a state diff is much much much higher than other tech. Much better to look at the tech I mentioned (Argo and Flux) for that, because they do state diff for these things in milliseconds. I’ll leave it to the reader to figure out how long it takes terraform to do this.
It’s possible to go entirely in the “everything is a kube manifest” direction using technologies like Crossplane and Cluster API and (for AWS) technologies like ACK. But I don’t think we are entirely there yet for these technologies in terms of maturity, so in my recent designs I usually settle for provisioning of cluster and initial bootstrapping with terraform before mostly handing off to Argo for deployment, but then doing this weird counterbalance for having to go back to terraform when infra stuff is necessary. I can see a future world, however, where you bootstrap management clusters with something like terraform but then basically everything else, both infra (clusters, buckets, IAM, etc) and deployments (Helm) is declarative through tech like Argo and Crossplane provisioning.
The tough part right now is when you have application devs that need to provision infrastructure and then deploy on top of it. Right now that looks like asking your developer to write some app specific terraform like S3/IAM/KMS/Redis/whatever and then deploying their app on top of it with Argo or flux or what not. The ideal maybe looks like using the same tech for both eventually, as well as even provisioning the cluster that the stack runs on with the same tech.
> Similar to the Forest Service’s proposed amendment, BLM’s rule was met with mixed emotions, with some conservationists saying it lacks teeth and some timber industry representatives saying it’s too restrictive.
Not even knowing how all of this works I can immediately tell BLM is walking the line on this well, because they are coming up with compromises that everyone grumbles about.
It certainly diminishes it significantly. Very few people are usually collaborating on the same branch together that isn’t the main branch in most orgs. So the chances of you destroying yours or someone else’s work that way is pretty low. You can also branch protect any arbitrary branch, at least on GitHub, though I’ve never been in an org that protects branches other than the main one, besides an org that used release branches. I’ve also never seen someone clobber someone else’s feature branch, though it probably does happen. Much more often people are accidentally clobbering their own branches.
The ability to rewrite history on feature branches is powerful in a good way and slots right into the way Git is philosophically designed. I would probably not be interested in removing that feature to prevent the rare case that someone footguns themselves or someone else
- Unplanned time off means the feature just doesn’t make it in
- Living in different time zones means that you just wait and work slows down
In either event, there is rebase and squash auto merge from major git providers like GitHub which helps with this a ton. With that enabled unless the repo is super high traffic usually this is an afterthought unless there is merge conflicts which is semi rare.
That being said, that’s just the reality of what I’ve seen play out in various organizations. I personally like to work off other people branches a lot more than my peers because I work in platform engineering and very often developers come to me with feature branches that need some CI/infra/other change or optimization and very often it’s easiest for me to just drop a commit into their existing branch. The change falls under their ownership and it gets mainlined along with their feature.
Im not OP but they are probably referring to the endless cycle of build tooling produced in the JS/TS ecosystem. Due to a multitude of reasons, the ecosystem produces a lot more tools in a much faster lifecycle than many other languages.
I'm talking about the pain at any point in time, p(t), over the long and complicated history of JavaScript. It looks like you are talking about the derivative of pain over time: dp/dt.
Well my pain got very significantly lower when I started to use React instead of jQuery and Ext.js, and then even lower with TypeScript. Since then the pain has been so low I ditched C# and switched to TS full-stack. Nothing I tried since then proved less painful.
It's not as good as it was in the Delphi days but that's because of many different target platforms and device form factors, than the technology itself.
I think we have much in common. Yes, I remember ExtJS. But not Delphi.
Yes, I remember the innovation of React and how it was a huge step forward relative to jQuery.
Roughly ten years ago, I used Clojure often, so I got to see the emergence of Om, then Reagent, and more. Somewhere along that time I saw Elm. Now, I see the innovation of Dioxus in the Rust + WebAssembly world. These developments were/are impressive. Part of fully appreciating them means embracing what they do better than JavaScript -- and many of these differences are incompatible with JavaScript's evolution. In a word, these other technologies are better largely because they have found a way to "break free".
If I were to try to "make a point" it would be probably be this: JavaScript, at any point in time, has been both useful and painful. Along the way, it has evolved remarkably well. The pain has lessened. With the birth of TypeScript, the experience is even more improved. But nevertheless, even with all the improvements, in some ways we're still paying down the "tech debt" rooted in some early decisions.
Some of the pain isn't necessarily around fundamental tech debt as much as community splintering. For example, I have a hunch, though I'm not an expert, that the Tower of Babel of JS tooling (such as bundling systems) may be resolved at some point. But I don't think this is likely until something else happens...
I look forward to a future where WebAssembly affords a direct, first-class, interface to the browser and DOM that provides high-quality, zero-cost abstractions. As great as WebAssembly is, there is still a considerable kludge in terms of how data is moved around at the interface between JS and WebAssembly. When this happens, it will arguably be a tremendous achievement -- to decouple web applications from the unnecessary constraints of JavaScript's historical choices.
I have a hope/prediction that stronger "competition" at the level of interfacing between the browser and the choice of language will spur better thinking and tooling. This gives me hope that the complexity of TS compilation + JS bundlers can give way to some elegant tooling, more along the lines of what the Rust community has achieved with Cargo.
That modem sequence is probably one of the most memorable pieces of a whole generation's childhood. If you ask me now, when it's been over two decades since I've heard it, I would easily be able to badly reproduce the whole 30 second soundbite with my voice from memory. With confidence I could probably nail every single beep and boop including the pauses between them and the odd static sound near the end of the whole process.
I used to invite mates over and move my hand like a wizard to change the frequency of the tones, not letting on that I'd memorised the whole sound sequence by rote and was messing with them.
Is the goose here the publisher? Or the author? If it’s the latter, then would killing the publisher necessarily dictate that the author also must die?
The goose is the entire book publishing system. Do editors, typesetters, cover artists, indexers, fact checkers, proofreaders, etc not add value to be recompensed? Is copyright (the exclusive right to make copies) not the sole fulcrum upon which rests the author and many others integral to books as we know them? Unlike music, it’s uncommon for authors to go on tour selling tickets and merch.
Most SaaS companies will tell you that they would rather not lock this important security feature behind enterprise. But the reality is that it is one of the few things enterprise will pay for and gate on and as such it’s become very effective as a differentiator. The edict to gate everything behind SSO is powerful in large enterprises and as such they will absolutely pay to be able to do that, making it a very easy internal sales tactic. The market has spoken, for better or worse.
I read your comment as saying that SSO is denied to “regular” (non-enterprise) customers because enterprise customers would buy the regular product if it was included there, thus pointing out that all the other “enterprise” needs (terms, etc) aren’t real?
Most enterprise features are nice-to-haves. SSO is a must-have for companies with enough security or compliance ceremony, which includes most enterprises.
Small companies don't need sso because when an employee leaves, they just go into all their sass and remove the user or change the password. A large company can't work without SSO because in an org with hundreds of users they can't login to each SASS and disable and enable everyone coming and going at the company, which is many per month in some cases.
This is very much correct, and quite self-evident: they live without, therefore they don't need it. Wanting something != needing it. Companies that actually need SSO are the ones that have internal or external compliance requirements, and/or for which managing users without SSO becomes prohibitively expensive. Turns out, at that point, they're willing to pay through the roof for it.
> quite self-evident: they live without, therefore they don't need it
Lots of people live without things others observe they need. Doesn't make going without a good idea.
> Companies that actually need SSO are the ones that have internal or external compliance requirements...
This logic is backwards.
Why do you think SSO is a "requirement" that security certifications or compliance policies look for? Why did that come to be? Who does SSO benefit? Are those personas relevant for only large companies or small ones too?
Do beginning drivers not “need” seatbelts or brakes? Or are these devices only needed to avoid tickets and pass inspection?
One thing worth pointing out. If you don’t mind using GitHub or Google you can get “SSO at home” for a lot of things, since most
SaaS provide Google/Github login in their lower priced tiers. It will usually be OIDC based and not SAML, but it’s definitely possible to use these providers up to a quite significant scale.
Why? You use SSO in your personal life all the time. Why would you not want to continue doing so in your business?
If anything, small companies need SSO more than any others - those companies usually outsource a lot (SaaS vs a dedicated hire), managing credentials is annoying.
SSO has lots of other benefits. MFA primarily. This is non negotiable these days, even for the smallest company. I’ve not seen many services supporting this without SSO.
Don’t get me started on the services that have their own smart ideas on what constitutes a safe password. Max 8 characters with no repeated letters and of which 4 must be an emoji, with automatic logout every 12 minutes. Yes those still exist.
Password policies are things you want control over in your IdP to avoid all this BS. SSO really should be standard.
> This is non negotiable these days, even for the smallest company.
Says who?
In reality, users don't care. Regulators, however, sometimes do, which leads to certifications and compliance requirements - and only then SSO and MFA become non-negotiable.
I work with a variety of small companies (5-25 FTEs) that are increasingly facing strict MFA requirements in order to maintain insurance. SSO isn’t an explicit requirement, but there are a myriad of general access requirements that they struggle to follow without some level of centralization via federated identity/SSO.
I helped out running a bug bounty program for a company whose large offering was a FOSS product a couple of years ago. Most of the people participating were either in very LCOL countries like Thailand or Montenegro, or were bored C level/founder people who would use the tiny amount of money as an incentive to keep their coding skills sharp since their day to day no longer involved coding.
reply