Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XML is the future

bitecode.dev

Post reply on HN
Print view View original

361–370 of 408 posts

Re: XML is the future

#361

Post by pathartl »

alphager wrote: post #145
devjab wrote: post #61

I worked a decade in public sector digitalisation in Denmark, where for some reason they still use a lot of SOAP and thus XML. I’m not so against XML in theory, but I hate it in practice. You’d have these completely over engineered solutions where you’d basically need to call a separate micro services for every “field” of anything. So if you wanted a name, a ssn, and, an address for a citizen you’d need to make sever…

I think "XML" is way too broad to meaningful discuss anything. XML the data format is pretty great in its basic form. Not space-efficient, but unless you're dealing with bulk data, the inefficiencies don't matter unless you're googlescale or can't spare a millisecond. The format itself doesn't absolve you from the design work of your model; your ssn example is typical of the "CEO said we have to use XML now" rush-job…

> XML data validation through XSD is a dream.

That assumes that the XSD is accurate. I'm currently working with a vendor that has probably the worst XML-based API I've ever seen and the XSDs they provide often don't provide 100% coverage and have bad complex type declarations, etc.

Re: XML is the future

#362

Post by xorcist »

sofixa wrote: post #291
xorcist wrote: post #248

Earlier quoted context omitted.

> Terraform provisions machines (and also infra, etc), and Ansible configures provisioned machines Ansible can provision virtual machines as well, and from my experience it is better suited for it too, since it doesn't save state outside the system. So there's lesser chance for it to get out of sync. It's mostly culture. People these days learn GKE or Kubernetes first, and their tutorials mention Terraform so that's…

> Ansible can provision virtual machines as well, and from my experience it is better suited for it too, since it doesn't save state outside the system. So there's lesser chance for it to get out of sync. State serves a purposes, it's not just there for fun. Ansible will lose track of your VM if you rename it (and can barely handle you renaming it with itself), and won't delete it if you just delete it from the confi…

> State serves a purposes, it's not just there for fun

The system has state. The question is how we want to manage it. The design in this case chooses to opimize to lessen the impact of errors. All real world systems are prone to errors in the long run.

If real world parables are excused: If the map (serialized state) and terrain (system state) differs, is it a good idea to insist on following the map?

> Ansible will lose track of your VM if you rename it

Sure, but so will Terraform. Or worse.

> won't delete it if you just delete it from the configuration

Sure it can. There are no limitations there. The only questions are whether you want it to, and how you want it to.

Ansible is a superset of Terraform. It's mostly a matter of culture which tool people choose, and which you think is the easiest to use.

Re: XML is the future

#363

Post by sterlind »

jerf wrote: post #309
edejong wrote: post #290

Earlier quoted context omitted.

CPU/Memory: scale horizontally when needed. Monitor cost. Disk: essentially limitless. If disk of VM runs out, node will crash, new node will start. Service should keep running on other nodes meanwhile. If restarts happen too often, throughput/error rate will suffer or cost will rise. Modern mentality is "let it crash" [0]. Software has bugs. Design so it can crash and scale depending on need. [0] https://medium.com/…

Letting an Erlang process crash is letting a process holding a small collection of resources, maybe a single TCP connection and several kilobytes of local state. It does not necessarily scale beyond that. Pretty much by definition, if you've got something that can run out of disk, when it runs out of disk and you nuke it, you're taking out a lot more than a single connection and a few kilobytes of state. And "let it…

I built a distributed system once on two principles: 1. let it crash, 2. make everything deterministic. obviously, this resulted in crashes being invisible and transient (good) or an infinite crash loop (bad.)

I haven't used Erlang, but my impression is that it's probably the same experience there?

Re: XML is the future

#364

Post by sofixa »

xorcist wrote: post #362
sofixa wrote: post #291

Earlier quoted context omitted.

> Ansible can provision virtual machines as well, and from my experience it is better suited for it too, since it doesn't save state outside the system. So there's lesser chance for it to get out of sync. State serves a purposes, it's not just there for fun. Ansible will lose track of your VM if you rename it (and can barely handle you renaming it with itself), and won't delete it if you just delete it from the confi…

> State serves a purposes, it's not just there for fun The system has state. The question is how we want to manage it. The design in this case chooses to opimize to lessen the impact of errors. All real world systems are prone to errors in the long run. If real world parables are excused: If the map (serialized state) and terrain (system state) differs, is it a good idea to insist on following the map? > Ansible will…

> If the map (serialized state) and terrain (system state) differs, is it a good idea to insist on following the map?

If you're doing landscaping and the map is your requirements, yes. And that's what infrastructure is comparable to (hence Terraform's name btw)

> > Ansible will lose track of your VM if you rename it

> Sure, but so will Terraform. Or worse.

No it won't, because Terraform stores the underlying platform ID in it's state. It will just know there was a rename, and will inform you it plans on rolling it back to what you have requested in the configuration. It won't delete it. Ansible will want to recreate it, with all conflicts this could bring.

> Ansible is a superset of Terraform. It's mostly a matter of culture which tool people choose, and which you think is the easiest to use.

It's a different tool for a different job (at which it isn't great due to using a markup language which really doesn't lend itself to templating with lots of templating, and a dynamic language that suffers from version and dependency hell).

Re: XML is the future

#365

Post by rerdavies »

firecall wrote: post #328
papruapap wrote: post #306

Earlier quoted context omitted.

create-react-app has been discouraged to use for a couple of years now, not really sure if the React team is still supporting it.

April 2022 was the last maintenance release. Out of curiosity, why is it discouraged? I’m not really in the React world, but have been fixing up a Create React App for a client recently, so learned a bit more about it.

So how are you supposed to create static react app now?

Re: XML is the future

#366

Post by c_crank »

akkad33 wrote: post #239
joegibbs wrote: post #231

Earlier quoted context omitted.

Also: software (at least the kind of software that results from hype-driven development) is much less dangerous, and there's a lot less that can go wrong if it fails. If you're working on a new kind of process for making some food ingredient you can easily do it wrong and poison someone, so people are naturally more cautious about trying new things. It's the same with software for e.g. nuclear reactors or plane contr…

What programming languages are typically used in such high risk scenarios

Ada was the DoD standard for a while.

Re: XML is the future

#367

Post by manvillej »

DarkCrusader2 wrote: post #245
gnulinux wrote: post #7

I've been working in the tech industry in the US for about 5 years. Ever since I knew myself I've been coding. From middle school to high school, given any problem, like Sudoku, or keeping up daily chores, my solution was Programming! Programming wasy homebase. Then I studied it in uni, thought I was kinda good at it, and loved it. But when I started working in the industry, I realized that it's absolutely exhausting…

I am in the exact opposite,but equally frustrating boat. In last 5 years, I have worked at 2 Faang and a large hedge fund and everywhere they had extremely outdated stack or undocumented in-house stack or outdated undocumented in-house stack. Already derecated dependencies were pinned years ago and management won't let you modernize anything since there "no business value in it" and we need to ship a feature instead…

In both of your cases, I think there is this massive disconnect in decision making. Software development is a constant game of economic decision making. Which investment returns the greatest value. Agile worked because it spread risk and allowed for reaction to new opportunities.

CICD/devops worked because it drastically reduced the risk & expense of defects, the cost of development, time to market, etc.

But the chasing of new technology fads vs lagging behind with old outdated technologies? I am seeing people make decisions without thinking about the decision.

What economic benefit does the new tech bring? Whats the economic trade off of implementing it vs other projects? How long till a return on investment? Whats the costs if we do nothing?

It isn't even that hard to do, but people just keep deciding to spend time and resources with little to no thought. It infuriates me.

Re: XML is the future

#368

Post by red-iron-pine »

gnulinux wrote: post #7

I've been working in the tech industry in the US for about 5 years. Ever since I knew myself I've been coding. From middle school to high school, given any problem, like Sudoku, or keeping up daily chores, my solution was Programming! Programming wasy homebase. Then I studied it in uni, thought I was kinda good at it, and loved it. But when I started working in the industry, I realized that it's absolutely exhausting…

> We just keep changing and changing the same things again and again because that's the new way to do

Capitalism doesn't work unless you have something to sell, and that's just as true for tech as it is anywhere else.

Re: XML is the future

#369

Post by wizofaus »

chrisan wrote: post #229
wizofaus wrote: post #128

Earlier quoted context omitted.

> This was the good-old-days when critical features were crammed in just days before a release Fascinating article, but really? I would have thought "cramming in" critical features days before release was more common these days, esp. if you're releasing/deploying to production on a daily (or even multiple-times-a-day) basis.

> esp. if you're releasing/deploying to production on a daily (or even multiple-times-a-day) basis. What does releasing regularly have to do with cramming stuff in? We release when stuff is ready. That could be multiple times a day or once a week. I think of people with set release dates as the most likely candidates of "cramming stuff in" because they fear they will miss the release and it might be a month (or worse…

Hence the quotes around "cramming" - it's now standard practice for the commits for a new feature to be merged into the mainline days before building a release. I can't say I ever remember doing that 20 years ago - there was always a code freeze period reserved for critical bug fixes.

Re: XML is the future

#370

Post by jerf »

sterlind wrote: post #363
jerf wrote: post #309

Earlier quoted context omitted.

Letting an Erlang process crash is letting a process holding a small collection of resources, maybe a single TCP connection and several kilobytes of local state. It does not necessarily scale beyond that. Pretty much by definition, if you've got something that can run out of disk, when it runs out of disk and you nuke it, you're taking out a lot more than a single connection and a few kilobytes of state. And "let it…

I built a distributed system once on two principles: 1. let it crash, 2. make everything deterministic. obviously, this resulted in crashes being invisible and transient (good) or an infinite crash loop (bad.) I haven't used Erlang, but my impression is that it's probably the same experience there?

The way it builds on immutability means it naturally can lean in that direction, but the way it tends to be used for networks a lot undoes that because network communication by its nature is not deterministic in the sense you mean.

In my case, IIRC, it was something to the effect of, a lot of our old clients out in the field connected with a field that crashed the handler. Enough of these were connecting that the supervisor was flipping out and restarting things (even working things) because it thought there was a systemic issue. (I mean, it was right, though I had it configured to be a bit to aggressive in its response.) The fact that I could let things crash didn't rescue the fact my system, even if I fixed that config, would strain its resources constantly doing TLS negotiations and then immediately crashing out what were supposed to be long term connections.

Obviously, the problem was in the test suite, we were able to roll back, address the problem, ultimately this was a blip not a catastrophe. I just cite it as a case where "let it crash" didn't save me, because the thing that was crashing was just too broken. You still have to write good code in Erlang. It may survive not having "great" code but it's not a license to not care.

Post reply on HN