This is Gold!
XML is the future
111–120 of 408 posts
Re: XML is the future
#112As per usual with XML I post my node/tree graph editor:
http://move.rupy.se/file/logic.html
Still works great, I currently use it to chop up sprite sheets and bundle them with my app as base64 encoded pngs! XD
XML must be the future.
Also use this parser: http://edit.rupy.se/?host=move.rupy.se&path=/file/Parser.jav...
Indentation from hell and some code missing but you get the point. No bloat... and XML! :P
Re: XML is the future
#113Earlier 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…
Having worked at both, the latter type of company also has it's downsides. Primarily: a) the inverse is also true...you'll be working on some old technology that only your industry utilizes and isn't well optimized for modern use cases or is extremely niche; despite there being plentiful use cases to make the switch, it'll never be "in the budget", b) your payrate is generally going to be quite a bit lower than indus…
> your payrate is generally going to be quite a bit lower than industry standards at app/tech companies
And so will be the workload. No semi-mandatory after-work drinking, no constant "hustling", no bullshit.
Re: XML is the future
#114[dead]
Re: XML is the future
#115I'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…
> it's absolutely exhausting I'm not young, yet I don't find any of this all that bad. Maybe I'm an outlier, but I see refactoring and learning new tools as just keeping the blade sharp. Migrating to new frameworks, tools, etc. is just superficially iterative. I've yet to see some kind of massive paradigm shift blow me away and stress me out.
I wanted to share my ideas, but it just turned into a rambling:
The problem is not with massive paradigm shifts... actually we are yet to see something like that. The constant busywork on industrial scale is what the problem is, the constant reinvention of the wheel in a way that is somewhat still incompatible yet the same thing. Most change is only for the sake of change, for NIH-syndrome. when a solution for a problem gets half-decent, and almost as good as it was in the windows 2000 times, then it gets forked/dumped and a new half as good fad appears...
There is no problem with learning new tools, but learning a new UI framework every 2 years just to be constantly half-as capable as Delphi was (okay, with rounded corners and animations, I give you that) can be really tiresome.
Cloud vendors changing their line-up constantly so that your certifications expire, and they can remove the really good value for the buck services and push the shiny new globally replicated and 10x more expensive new stuff (which delivers value for many, but the barebones stuff also did for many others).
Just my 0.02$, probably saw too many lets rewrite in $current-thing and don't use $industry-standard-battle-tested-thing, as it is hard to learn it, but let's write one from scratch! (last time a team in a job decided that configuring HAProxy (my suggestion to get stuff done cheaply and quickly) is too hard, it is better to write a high performance reverse proxy, because it will be our thing! (I guess they were more interested in their resumes than in the company's interests). Since then that company is bankrupt... who would've thought)
Re: XML is the future
#116It's easy to just mark XML off as one of the many fads in tech given how many there are. But I think it's much more worthwile to dive into the particulars of why it failed. While they're all fads, some of them share commonalities that, in hindsight, I think we can say were major catylsts to their downfall. With XML, it failed because something like JSON was much simpler. Time and time again I see people saying that j…
> With XML, it failed because something like JSON was much simpler. I remember when XML was pretty new and I used this new-fangled technology called XML-RPC. XML-RPC was amazing and I was using it to connect desktop applications to web applications. If you go look it up, you'll notice that bears a striking resemblance to JSON. But what technology actually took off for RPC in XML? SOAP. And SOAP is a nightmare of comp…
Adobe Flex front end connected via xml-rpc to a python backend was my favourite way of whipping up personal desktop utils back in the day.
Re: XML is the future
#117I'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…
Yeah, you can't jump on every hype.
I started in web dev almost 20 years ago (did some Visual C++ before that). First job was everything XML. We had our open source CMS that stored all documents as XML and used XSLT to transform it into the HTML we needed. Was pretty cool, but there's always something that didn't fit that paradigm. Some coworkers went a bit overboard and used XSLT to generate the XSLT to create the HTML. But it all works as long as you cache aggressively.
Second was Ruby on Rails with JQuery. And eye-opener for me. Very cool to work with. Third job was similar, but using Groovy instead of Ruby. After that, I ended up in SPA-land: first Angular, then Vue, now React. Backends in either Java or Node.js.
I'm still doing that, only now everything needs to be in Docker and Kubernetes.
I still don't know why I should ever need microservices. Our GraphQL. We actually considered GraphQL for previous project, and decided not to because it looked way too complicated. It sounds like it might fit with using a Graph DB (I'm a big fan of neo4j), but it doesn't. At my current project, they made that decision before I joined, and they've since realised that they don't need GraphQL after all, but it's in there now, so they just work around it.
Some of the hypes worked very well for me (XML, jQuery, Ajax, SPA), others seem to work well for others but not me (docker, kubernetes), and some I really don't see the point in (microservices, GraphQL), but I assume there are use cases where they shine.
But don't blindly adopt everything. First check if it actually fills a need you have. And how it will fill that need.
Re: XML is the future
#118I 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…
At the tax authority we could query that directly from a database.
But yes, the public sector suffers from countless different systems that have accumulated over the years. It happens because everything has to go out to a public bid and throughout the times it has been considered anti competitive to built things in-house.
Re: XML is the future
#119I 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 agree that there is nothing inherently wrong with XML, the problem is with the way it is used. I have worked with great XML schemas, and terrible ones also. Also the XML APIs in the programming languages are a bit dated, and oftentimes a bit cumbersome to use. Yet the standard API to support not only DOM style, but streaming parsing is also a great thing, should you have to process several gigabytes large XML files at one time on your career (as I had to).
Re: XML is the future
#120XML is very much misunderstood. The hype that surrounded it was for a good reason, because XML is somewhat unique as a concept. There was nothing like it and still isn’t. It is not a data format or something like that. It is a notation tool. Normally you invent some syntax and parse it to get what is called “abstract syntax tree” (AST). With XML you work directly with an AST. Parsing from text is convenient because y…
You could say the same about JSON. It is arguably closer to how and AST is represented in software as it does not posses the two dimensional notation like XML does. The unique thing about XML is that you can both have children and attributes. My guess it that this is to model OOP-based systems: Attributes are for the constructor or a certain class while the children represent dependency injections. This is IMHO the w…
> It gives too many levers.
I don't agree that the horrible XML example is the result of that.
There's a simple semantic difference between attributes and elements in XML:
* there's only one instance per attribute
* attributes are atomic (i.e. have no children)
* attributes are order-independent
So whenever your data is atomic, the order in which it appears doesn't matter, and you only want one instance, (per element) you'd use an attribute. The reasoning behind this is to enforce basic semantic rules without having to resort to complex schemas like XSD or RELAX NG.
It has nothing to do with OOP: it's just a very basic tool for enforcing basic constraints. As with every tool, it can be misused or ignored. The XML example is the result of incompetence and/or lack of coherence in data modelling and processing (judging from the micro services mentioned), not a weakness of XML as such, IMO.