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

281–290 of 408 posts

Re: XML is the future

#281

Post by Cthulhu_ »

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…

But the issues you describe isn't XML's fault, it's poor oversight and lack of consistency from developers. Does anyone have an architect or API designer hat at your company? They should be responsible for designing the XML structure, setting rules on where values go, etc.

This is an issue that you will have with every kind of data transfer / representation tech, be it XML, JSON, protobuf, etc. Someone needs to have ownership, someone needs to set a standard, and everyone working on it should stick to that.

Re: XML is the future

#282

Post by brightball »

This hype cycle was at the very start of my career. “Java and XML! Portable code and portable data!” was the big slogan.

I took a course on XML, DTD, XSD, XLST, JAXB, etc. It was everywhere. There were tools specifically to design XSD schemas, so that you could generate classes for them using JAXB and validate the data.

SOAP and XML Web Services were everywhere, using WSDL which was a glorified XSD. The WSDL would allow you to generate a client library and validate the data prior to making an API call. It was pretty useful and I still prefer it to REST, despite its warts.

Such a distraction though. All of the obsession with perfected static types and schemas got in the way of any productive work.

When I discovered how much more I could accomplish with a dynamic language and a SQL database I never looked back.

Re: XML is the future

#283

Post by dicroce »

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…

The way that I have avoided burnout for all these years is working on my own projects, and building them exactly the way I want to. This gives me the strength to grind through the shitty work I am paid to do.

Re: XML is the future

#284

Post by eschneider »

plorkyeran wrote: post #47
rqtwteye wrote: post #15

Earlier quoted context omitted.

The sad thing is that in many cases working on such a system is a career killer. Nobody wants to hire you. Some years ago a colleague and I realized that our company wouldn’t hire us judging from the job descriptions because we worked on systems that had been working for years but weren’t shiny. Since then I always something new to every project. Not because it makes sense but because it’s good for the resume. Other…

I think this fear is not entirely wrong, but is significantly overblown. There's a significant gap between what job descriptions ask for and what companies will actually hire. A resume full of dead technology isn't going to help you ladder your way up to bigger and higher-paying roles, but it's also not going to make you unemployable. A resume full of less-shiny but still relevant technologies, otoh, has a lot of pot…

When I look for a new position, I try and make sure it’ll allow me to learn a new fundamental skill rather than the latest new framework (though often there’s overlap:)

Over 30 years that’s allowed me to be employable across a lot of different tech stacks.

Re: XML is the future

#285

Post by steveBK123 »

steveBK123 wrote: post #269
xorcist wrote: post #244

Earlier quoted context omitted.

> In the meantime, your PHP app had 40 major security flaws, no meaningful monitoring, How does Kubernetes, microservices and front end frameworks fix that? They don't. In fact, as someone who works at the more modern end of these things, I'd suspect that "no meaningful monitoring" probably correlates quite well with cloud era microservices thingies. But we can't blame the tools, that space is just younger and by nat…

As a "not a cloud guy" who only recently got heavily exposed to it.. I found the state of the art / CloudOps attitudes towards monitoring astonishingly Stone Age. Yeah observability is great, but no one I've seen in cloud manages to launch with it. So in place of SRE org with full observability stack, they launch with effectively nothing. Strong attitudes of "we don't measure hardware metrics like cpu/memory/disk, we…

And I would add - All the GOOD cloud people I know are GOOD linux people. It is a prerequisite.

However theres lots of cloud people who don't know linux.

Therein lies the challenge. Too many of these cloud devs forget that whether its "server less" or not, theres a .. server, somewhere.

All the layers of abstraction work when they work, and when they don't .. best of luck figuring out what's going on in a timely fashion. Hope you aren't running any money on top of it.

Re: XML is the future

#286

Post by sickcodebruh »

Doesn’t this strike anyone as overly cynical and just… incurious? Yes, hype and trends are obnoxious, there are individuals and organizations that reflexively seek sexy tech and apply it wrong, but isn’t this also part of how we find things that work and things that don’t?

It’s easy to run through decades of tech trends and present them as the only things that dominated the industry, just like it’s easy to rattle off one-hit-wonders or movies that flopped and claim that the arts are dead. But I remember Apache fading in favor of nginx. MySQL being shouted down by Postgres. Frameworks like Rails and Django becoming popular over the LAMP stack (with the aforementioned A and M…). Docker over Vagrant for dev environments. TypeScript, unidirectional data flow, the decline of OOP. I can go on and on and these are just the ones that spring to mind immediately!

I’m still very much a “choose boring tech” guy. I also sometimes feel frustrated by how fast technology changes and how the winners of hearts and minds are often the result of marketing effort, not good technology. But unless you’re a technology blogger, you probably don’t need to be bothered by this. New tech emerges for a reason. Some of it will be overhyped, some of it will be unfairly ignored, some things will win and some will lose. I feel fortunate to live in a time when there’s so much enthusiasm and creativity for new ways to solve old problems.

Re: XML is the future

#287

Post by edejong »

xorcist wrote: post #244
edejong wrote: post #179

Earlier quoted context omitted.

In the meantime, your PHP app had 40 major security flaws, no meaningful monitoring, a DB that wasn't backed up and major data consistency problems. Also, when your box's hdd crashed, you lost all those minor changes you had vim'ed over the years. But for the rest, yeah, all is fine.

> In the meantime, your PHP app had 40 major security flaws, no meaningful monitoring, How does Kubernetes, microservices and front end frameworks fix that? They don't. In fact, as someone who works at the more modern end of these things, I'd suspect that "no meaningful monitoring" probably correlates quite well with cloud era microservices thingies. But we can't blame the tools, that space is just younger and by nat…

* k8s helps because you keep your application online during rolling updates. You keep your changes relatively small and can test your changes in isolation.

* microservices help security because for each service you write, you create a minimal surface area (as opposed to monolithic applications where each method has access to maximum dependencies).

* microservices also help monitoring, because failures can be contained and one application does (should) not impact another. This means that your focus of monitoring is on application performance, and less on the underlying system architecture.

* monitoring can be a cross-cutting concern. For example, you can monitor all HTTP requests by instrumenting your ingress layer. Similarly, you can support a unified authorisation scheme by bringing this to the ingress layer. Even more, using microservices, you can independently promote services to production (sort of like feature toggles) or do green/blue promotion.

* security of your microservices is improved, because you can independently upgrade your dependencies per service. Many older monoliths are 'stuck' in a certain dependency configuration and cannot be upgraded without a 'big bang' of expensive dependency resolution and testing.

I could give many more examples, but I hope this captures the spirit a little.

Re: XML is the future

#288

Post by yxhuvud »

jononomo wrote: post #271
noduerme wrote: post #19

Earlier quoted context omitted.

I've watched this happen to so many coders in the land where people write code for companies that sell code . Personal advice: Write code for any other kind of company. They're much more resistant to fads. They don't care how you accomplish the new feature. They just want to get it done. And they certainly don't want to change their stack, ever , although in a new project you'll have more flexibility to pick the righ…

This is how you get stuck working with XML in 2023, as is the case with a woman I was just talking to the other day at my co-working space.

Another way is to work at one of the many places where XML (and related technologies like XSLT) make perfect sense both then and now. Working with transforming documents from one representation to another is a work that will not disappear anytime soon.

Re: XML is the future

#289

Post by sofixa »

hardwaresofton wrote: post #71
andrewflnr wrote: post #58

Earlier quoted context omitted.

I would phrase almost the same idea from the opposite angle: focus on the fundamentals that never change, and view the trends in terms of how they relate to those fundamentals. But also, those are some pretty odd comparisons. For sure Ansible and Terraform aren't directly comparable. If anything they're complementary. Terraform provisions machines (and also infra, etc), and Ansible configures provisioned machines.

> I would phrase almost the same idea from the opposite angle: focus on the fundamentals that never change, and view the trends in terms of how they relate to those fundamentals. Definitely -- I'd say that these questions force the understanding of the fundamentals, because that's what you get down to ("fundamental"/irreconcilable differences). The problem is that fundamentals can be similar, and sometimes the differ…

> What you've said is the usual rebuttal (and it's mostly right!), but did you know that Ansible did/does provisioning?[0] The lines aren't drawn as neatly as they seem to be.

In the same way that a toaster can be used as a hammer if you hit nails hard enough with it from the "correct" side. Ansible barely does it's main purpose, configuration management, but abusing it for provisioning is just on a different level. Even overlooking the extremely narrow feature set, just `state: absent` should be enough to convince anyone Ansible just isn't made for provisioning. Add it the bolted on templating of a configuration language that uses spaces for logic, the fun of Python dependencies of which you need a ton to do any provisioning, and you're just in for a massive world of pain for literally no reason.

Disclaimer: I work at HashiCorp, but not on or with Terraform, and have had a disdain for using YAML for anything other than basic configuration and Ansible for anything other than simple, basic, low complexity and low scale Configuration Management since I inherited an Ansible project to manage VMware configuration in a past job.

Re: XML is the future

#290

Post by edejong »

steveBK123 wrote: post #269
xorcist wrote: post #244

Earlier quoted context omitted.

> In the meantime, your PHP app had 40 major security flaws, no meaningful monitoring, How does Kubernetes, microservices and front end frameworks fix that? They don't. In fact, as someone who works at the more modern end of these things, I'd suspect that "no meaningful monitoring" probably correlates quite well with cloud era microservices thingies. But we can't blame the tools, that space is just younger and by nat…

As a "not a cloud guy" who only recently got heavily exposed to it.. I found the state of the art / CloudOps attitudes towards monitoring astonishingly Stone Age. Yeah observability is great, but no one I've seen in cloud manages to launch with it. So in place of SRE org with full observability stack, they launch with effectively nothing. Strong attitudes of "we don't measure hardware metrics like cpu/memory/disk, we…

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/@vamsimokari/erlang-let-it-crash-philosop...

Post reply on HN