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'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…
XML is the future
271–280 of 408 posts
Re: XML is the future
#272Earlier quoted context omitted.
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…
> The insistence of the JSON-people to sabotage any kind of data validation is absurd to me. I don't understand what you mean by this. JSON supports schemas which can be used to validate input. It's not super advanced, but it's functional.
It just about works, but it's horrible to write and horrible to maintain. What you can actually do with the validation is surprisingly limited in some forms and the fact that you have to write JSON to write the schema shows just how non-user-friendly JSON is.
A friend told me that she writes JSON schemas in YAML and then uses a build step to downgrade that to JSON for the actual validator. I wish I'd thought of that.
Re: XML is the future
#273Earlier quoted context omitted.
> won't matter as much if they're about erasing your directories or killing your machine Those sort of attacks have tapered off though, right? Unless you're engaged in a specific feud, or have caught the ire of a social justice warrior, these days we're mostly looking at data exfiltration as the primary goal. That being said, there are a lot of ongoing feuds and active social justice warriors.
If we're talking about common, automated attacks, I think the game plan for the past few years has been to probe for systems vulnerable to RCE, install a crypto miner, join the server to a botnet and see how long it takes its owner to notice.
Re: XML is the future
#274I 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…
Another piece of insanity is the e-TL (elektronisk tinglysning) SOAP service. Getting a non-java client generated is a PITA because of the use of the java Catalog feature. Even after hacking around it by setting up a local webserver and liberal abuse of the host file the generated .net WCF client needed manual fixes in a lot of places.
After doing that your calls still fails. It turns out the service wants the client to tell it which xsd to validate the request against (?!?). Also did I mention that the service expects every request to be signed, even when only reading information - it doesn't do anything to validate the signature though.
Re: XML is the future
#275Some thoughts of why software is so hype prone and will likely remain so, if not accelerate * Its intrinsically easy to come up with new approaches. Thinking and writing software is a mental process, it is not limited by physical constraints and messy manufacturing. * The scope of use contexts in society exploded. You only needed the formula-translation language when you had five whitecoats in a research lab punching…
I think you left out the main factor which is that programmers are people and people subconsciously copy what other people are doing. We are herd animals. Also most people are not really good at judging novel things and are mainly influenced (subconsciously) by surface appearance and popularity.
For software people it is sometimes easy to forget that in most other professional domains exchange of real information, detailed opinions etc. is still much more siloed and inaccesible. It does not happen out in the open. This has a dampening effect as copycat behavior spreads much slower.
Re: XML is the future
#276I'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…
Re: XML is the future
#277I'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…
Things will be tougher when management starts asking for real, measurable results.
Re: XML is the future
#278Earlier quoted context omitted.
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…
Maintaining old stuff is way more sensible than rewriting everything every few years. Companies tend to measure costs of maintenance vs rewrite. Edit: there's always a tradeoff but I wrote "every few years". Cobol is an odd example. Many banks have been going back to Cobol because they found it less expensive than the alternatives and are there is an influx of new graduates learning the language right now.
Re: XML is the future
#279But some people ran away with the idea and extended it to uses that should have never been done in XML such as streaming.
Re: XML is the future
#280Earlier 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…
> How does Kubernetes, microservices and front end frameworks fix that? Doesn't being in a container mean its much easier to rebuild it from zero and thus allowing security updates to be more regular?