|
The harsh light of reality:
0) I'm going to go out on a limb here and say no, you most likely won't be "job-ready" in three months, and even at 6 months, it would be a stretch. BVeing a software developer requires a certain mind set and aptitude.
1) If you thought the pay was bad in the architectural business, wait till you try to find a job as a programmer with no formal programming (or even IT) related education.
2) I've been programming for 40 years, and still wonder if I'm "job-ready"...
3) I can't imagine how difficult it is to start out as a new programmer nowadays. You're going to have a rough time of it at first - the pay will suck, the hours will be long, and the job is generally thankless, with clueless managers basking in the glory of your efforts. You'll likely spend YEARS on a given project, only for it to be abandoned or marginalized, but you should look on the coding you did as a learning experience and move on.
Advice:
0) Get an account on Pluralsight. They have training for pretty much anything IT related you can imagine.
1) Develop strong google foo. If you can't google for the info you need, you'll be stuck buying books that will only be viable for a year or so (yes, the industry changes that fast).
2) I think it would be easier/faster to become a SQL developer than an actual application developer, because SQL will always be SQL and changes at a much less frenetic pace than does application development.
3) Even if you don't become a SQL developer, you still need to learn SQL for most jobs nowadays, on top of being an application developer.
4) You HAVE to be willing to write code as a hobby. Many times, you have to learn new tech for something you're going to be doing at work, and managers don't generally want you to "learn" on the job. They expect you to miraculously just know how to do shit that is only a few days old.
Other stuff:
0) The one bright light is that most of the tools you need will be free, so, silver linings.
1) Get decent modern hardware. At least a quad core CPU, a bare minimum of 16GB of RAM (32 would be better), and a SSD hard drive (they're really cheap compared to even a year ago). Beyond that, at least two monitors would be really useful as well.
2) When you think you're ready to get a job as a developer, read this article - Being a Programmer[^]
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: you'll be stuck buying books that will only be viable for a year or so (yes, the industry changes that fast).
It's not like a book on .NET 2.0 is suddenly non-viable. How old is the head first c# thingy now?
#realJSOP wrote: 2) I think it would be easier/faster to become a SQL developer than an actual application developer, because SQL will always be SQL and changes at a much less frenetic pace than does application development.
I like my SQL92, yes, but querying a database is not development, and is not often asked as a standalone skill. If someone is designing a database, you'll need to know a few things more than just SQL.
But yes, your post is spot on 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: How old is the head first c# thingy now?
I don't even know what that is.
Eddy Vluggen wrote: querying a database is not development, and is not often asked as a standalone skill. If someone is designing a database, you'll need to know a few things more than just SQL.
I know some sql devs who will rabidly disagree with you. SQL dev work is (I think) significantly different from app dev (using the various languages available). You gotta think a whole different way. You also have to thoroughly understand the db environment.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: I know some sql devs who will rabidly disagree with you.
Why?
#realJSOP wrote: SQL dev work is (I think) significantly different from app dev (using the various languages available).
It is. Querying is not programming.
#realJSOP wrote: You gotta think a whole different way. You also have to thoroughly understand the db environment.
Some database-theory, like normalization.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: It is. Querying is not programming.
We have stored procs that are as long as 1400 lines (which I personally find disturbing). Believe me - it's programming, and you're significantly over-simplifying it.
Out of the hundreds of stored procs we have scattered over more than a dozen databases, we probably have five or size that are simple select queries.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: We have stored procs that are as long as 1400 lines (which I personally find disturbing)
I've seen someone be "bright" and store 31 booleans as 0 and 1 in a string. Having it doesn't mean it is a good idea.
#realJSOP wrote: it's programming, and you're significantly over-simplifying it.
Writing a sproc is manipulating data, yes, but it is not programming, nor is that the most important aspect of a DBA-position.
#realJSOP wrote: Out of the hundreds of stored procs we have scattered over more than a dozen databases, we probably have five or size that are simple select queries.
Sounds like a maintenance-dream for anyone who is afraid to run out of work 
I don't care about sprocs, they are a layer on the db-structure itself; and unless that structure is in 3.5 NF, I'm not touching it. How would your boss react to that? 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I think you 2 are discussing the difference between a programmer and a developer. The latter will be expected to have database skills.
The OP does not know the difference.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Mycroft Holmes wrote: I think you 2 are discussing the difference between a programmer and a developer.
Nah, IMO writing an sproc is "scripting", which is a user-acticity, like scripting in VBS. If you want to program, you need a programming language, not a scripting-language.
And for most people in this world, a programmer and a developer are the same thing
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: writing an sproc is "scripting", which is a user-acticity
You're seriously kidding, right?? The time I've spent over the past quarter-century rewriting badly-written SPs (written by junior devs, not even users) is substantial, and the effects of their efforts at destroying database - and therefore application - performance and thus usability is even more so.
I'd argue that a SQL Dev is not someone who knows how to write a SP, but someone who is capable of taking business requirements and designing a suitable structure (which involves a lot more than just normalization) AND access model, and then (maybe) is also able to develop SPs. Those SPs also require debugging skills. The conversion of business requirements to database model is not done in isolation, but requires a deep understanding of the way the (proposed) application(s) will function and very close liaison with the other developers.
Also, there are elements to SQL that maybe you've never come across if all you've needed to do is "run a query".
|
|
|
|
|
DerekTP123 wrote: You're seriously kidding, right??
No, it would have a joke-icon if I was, and I don't find this funny at all.
DerekTP123 wrote: The time I've spent over the past quarter-century rewriting badly-written SPs (written by junior devs, not even users) is substantial, and the effects of their efforts at destroying database - and therefore application - performance and thus usability is even more so.
So? Most of it is not done by a trained DBA.
Also, "user" is not limited to untrained personel that only uses the GUI someone built. YOU are an end-user for some products, even as a developer.
DerekTP123 wrote: I'd argue that a SQL Dev
There is no argument.
DerekTP123 wrote: is not someone who knows how to write a SP, but someone who is capable of taking business requirements and designing a suitable structure (which involves a lot more than just normalization)
I never claimed that normalization is all they need to know, that's just a shortcut for me to evaluate what I am dealing with. A DBA will happily chat about the difference between the logical data-structure and the difference with the structure on disk, and can actually explain the performance-statistics that SQLSMS generates when executing a query. Being proficient with SQL is not enough, but that also goes for any developer worth its salt.
DerekTP123 wrote: but requires a deep understanding of the way the (proposed) application(s) will function
The app does not determine how the database is structured; the app is merely a layer, and will have to use the structure as determined by the DBA, which will base it on requirements. That's requirements for which data to hold, not for what the app should be able to do.
So, no, nowhere do I imply that a DBA is the same as your end-users. Some years ago, EVERY user needed training for their tasks. Nowadays, people with training are considered too expensive.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Some interesting responses there, and I think we agree on much. However I'd still contest that letting end-users - even with reasonable SQL skills - loose on writing Stored Procs is a bad idea. For one thing, in very many scenarios, the end-user does not (or should not) have permissions to see the full structure of the tables they're dealing with, and certainly not a deeper understanding of the database structures - nor of other applications that also need to access the data.
For low volume (size and transaction rate) databases it might not hurt too much, but a single badly-written (by which I don't mean poor syntax, I mean inappropriate for the situation) SP can wreak havoc on a high-volume or high-activity d/b.
Eddy Vluggen wrote: Being proficient with SQL is not enough
which I think is the point I was trying to make; probably failed to express it well.
Eddy Vluggen wrote: The app does not determine how the database is structured; the app is merely a layer, and will have to use the structure as determined by the DBA
Generally, I'd agree with you there; however I think it's often a chicken-and-egg situation, and I've experienced places where "[the application developer] will have to use the structure as determined by the DBA" has caused not only poorly-performing apps, but also project over-runs and severe internal ructions. Too much delineation between roles, lack of communication, inflexibility and "empire-building" is never good. Development involves ongoing negotiation and collaboration and a new app with a unique access pattern may require more than just whacking in an extra index or two!
|
|
|
|
|
DerekTP123 wrote: However I'd still contest that letting end-users - even with reasonable SQL skills - loose on writing Stored Procs is a bad idea.
And then MS Access was introduced, lowering the required skillset to manipulate data in SQL Server. Look at me, I clicked together a delete-query!
Why does it say "no records found" when I run it again?
DerekTP123 wrote: I've experienced places where "[the application developer] will have to use the structure as determined by the DBA" has caused not only poorly-performing apps
So? My first guess is an incompetent DBA - they usually know more about performance in a DB-environment than me. SQL Server in particular has these statistics that it gathers, and a good DBA will explain the cost of every word in your query.
DerekTP123 wrote: Too much delineation between roles, lack of communication, inflexibility and "empire-building" is never good.
Empire building? This isn't politics, but a definition of roles, and a delineation of profession. I do not go into the kitchen in the restaurant, regardless of politics - it is not my profession, and though I can cook, I really shouldn't do so in a professional environment.
DerekTP123 wrote: Development involves ongoing negotiation
In over 20 years, I never negotiated. Sales negotiates, my boss does.
The person responsible for the data-integrity and the servers performance is the one who determines how the data is stored. If you as a dev need it in another format, the DBA will provide you with an appropriate view, or generate a temp-table.
How many programmers can explain the different locking-mechanisms? How many can explain a clustered index? Most that I know don't even care about a primary key - they'll add an autonumber or GUID and be done with it.
DerekTP123 wrote: a new app with a unique access pattern
Having a DB means you are following a standard in how to store data. That's hardly unique, no matter how important you think your product is. If you use an RDBMS, you follow the rules of the DBA, because a DBA is trained for exactly that.
DerekTP123 wrote: collaboration
I never done that either; I'll listen to what the client needs, then I'll explain the client how I will implement a solution. Simple example that runs parallel to the DBA-discussion - lots of clients will want a word on how the UI looks. None of those will have had any training with respects to UI-development, and don't know sh*t about accessability-features. So no, I will create a UI that I think is required, not what the client thinks that is needed.
Arrogant? No, not at all. Walk into the restaurant of a kitchen, try to collaborate and negotiate a fried egg with the chef. You'll be out of the kitchen before you can start a discussion, because they have work to do. And no, your eggs aren't that unique
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
MS-Access - exactly my point. Just cos an end-user wrote a query against a table in Access doesn't mean they should be let loose writing SPs against the corporate database.
Incompetent DBA? No, just a DBA that has not been properly involved in the applications' development. You seem to feel there's one single solution to any given data structure, without taking into account the use cases against that data. A design that might allow for lightning fast single-row updates might be a complete dog when running summary reports. If you allow the DBA to dictate the *only* possible structure without proper liaison you end up with inappropriate solutions.
Empire building - in your example, that would be the chef telling the customer what they were going to have for dinner. The customer wants a vegan salad, they get served a rare steak - not a great outcome.
"I never negotiated". All of life is a negotiation. What I mean by negotiation is a sharing of needs - requirements - which may be an iterative process until both parties are fully satisfied they understand the other's position. As for locking mechanisms etc - exactly, a lot of programmers neither know, nor appear to care, what havoc their procs wreaks on other applications or even their own. And you expect an end-user to knock up a SP as though it were a macro??
By "unique access pattern", I don't mean globally unique. I just mean doing something with that database that hasn't been done before. Your solution is for the DBA to provide a new view or temp table. That may be the right solution, or it might be something more "radical". Either way, it involves the DBA and is often not something the "end user" can resolve by themselves.
As for never collaborating, well done on having a career that involved zero teamwork. I've been freelancing a quarter century now, and it's all been about collaborating. A good software developer doesn't just sit hunched over a terminal, they are involved with people - end users, DBAs, graphic designers, hardware planners etc.. There are ways to tell a client that what they're asking for is the wrong thing, but the best way is always for the client to come to that conclusion themselves. Collaboration and negotiation are the "soft skills" that the IT industry is finally waking up to realising are as important as technical ability.
Anyway we've wandered a long way from the OP's original question! If they're still following this, though, maybe it will give them some food for thought... if only that there's more to this development thingy than meets the eye 
|
|
|
|
|
DerekTP123 wrote: taking into account the use cases against that data. A design that might allow for lightning fast single-row updates might be a complete dog when running summary reports.
Incompetent DBA and incompetent developer. A DB is designed to be optimized for speed, so "lightning fast" has no meaning there; it a consultants term. One can also simply export-copy a part of the DB for reporting 
DerekTP123 wrote: If you allow the DBA to dictate the *only* possible structure without proper liaison you end up with inappropriate solutions.
The DBA owns the server and the data. If he doesn't, he cannot guarantee consistency of the data. How many of the other people involved have done the DBA's training? Where does the arrogance come from to explain the DBA how he/she should do their work? If the work is so simple as you explain, you don't need anyone with an education - since you know it better anyway!
What happens in practice is that the DBA caves in to threats and continous whining, delivers something that he doesn't fully support, and leaves before the sh*t hits the fan. You don't tell the cook how to cook, you don't tell the DBA how to administer his database.
DerekTP123 wrote: Empire building - in your example, that would be the chef telling the customer what they were going to have for dinner. The customer wants a vegan salad, they get served a rare steak - not a great outcome.
Hahaha, most costumers will not accept that, but that hardly requires negotiations in the kitchen. Once you place your order, negotiations are over.
DerekTP123 wrote:
"I never negotiated". All of life is a negotiation.
Ah, so now we use philosophy to justify the extra talking? How about biology, as everything we do is related to sex? All life is about sex, not negotiating sex.
I write code, and do not negotiate. Never have in what's now nearly 25 years of work. The idiots that keep on negotiating are usually the projects that fail. There's a problem-statement, there's specs, there's a way to turn specs into code.
DerekTP123 wrote: I just mean doing something with that database that hasn't been done before.
There's nothing that hasn't been done before with databases. Your ideas aren't that unique, as I already explained.
DerekTP123 wrote: ollaboration and negotiation are the "soft skills" that the IT industry is finally waking up to realising are as important as technical ability.
Collaboration is a bullshit term. Devs work in project teams, and collaboration is nothing new for them. We will even work with people we never seen. Lots of Open Source to prove exactly that.
Negotiations aren't a dev-skill either. Yes, a recruiter will wet their pants when reading those words. Also, the project-team has a sprint to do, and the project-lead should kick your negotiating arse out too - there's a price on what has been agreed, and the lead should not renegotiate.
DerekTP123 wrote: A good software developer doesn't just sit hunched over a terminal, they are involved with people - end users, DBAs, graphic designers, hardware planners etc..
That's not a developer. We don't need to talk to everyone, because there are specs. The graphics designer is ignored a thousandfold, as I determine how the UI will work.
We also do not disturb the people who make hardware; if we need to work together, we'll talk about and define an interface. Last thing we need is more politics in IT, there's already too many people that talk alot, cause more confusion, and do not bring any added value to the table.
..and before you state I lack the soft skills; I'm rather good at it. Might be due to the fact that we never had "collaboration" and "negotiation" in our schooling, but things like "working in a project" and are good enough at our work that we need not hide in countless meetings that lead nowhere.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: before you state I lack the soft skills; I'm rather good at it.
so much so that you've repeatedly failed to read and understand my comments, including my hint at the end of my last post it was a time to draw a line underneath this sub-thread.
I congratulate you on a most apt signature line.
Cheers and goodbye.
|
|
|
|
|
DerekTP123 wrote: so much so that you've repeatedly failed to read and understand my comments, including my hint at the end of my last post it was a time to draw a line underneath this sub-thread.
No, disagreeing does not mean I don't understand your petty point of view.
DerekTP123 wrote:
I congratulate you on a most apt signature line.
Thank you. A convenient way for you to get out while you can.
DerekTP123 wrote:
Cheers and goodbye.
Cheer
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I do not think that anyone will hire you after 3 month - intensive as be - learning...
You say that you are "pretty good with computers generally", but on what level? My mother mastered blogging in two week (started at age 65), but it doesn't mean that she can program a blogging software...
I would take an easy - half time? - job to keep money in balance a bit, but to left time for some serious research...
First step I would recommend is to find a small challenge and check if you can do it without any help, just doing your research on your own - if you find all the messing around with the unknown, it is probably for you and you can look for something to learn...
As you have not much time to stat actual work, I would look into the current job list around you and aim for one of those - like front-end-for-the-web...
Learn it well - apply for a job - and continue to learn while you are working...
All of those are serious about it learn every day of every week, it does not work without it - you have been warned!!!
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
|
|
|
|
|
The first piece of advice I will give is never listen to any advice including my own, which is why I won't be giving you advice
But I think I can offer you encouragement.
Having come from architecture I think you are in a very good position. I am going to make a guess that maths plays a fairly big part in your previous training and work. If that is the case you are at a distinct advantage.
I am one of those who struggles a bit at maths. As a 49 year old developer who works with younger developers far more talented than me when it comes to writing code, I have noticed those developers with a solid maths background are always those who are the best at pure programming and solving problems.
Fortunately for me there is more to being a developer than just banging out code, which is why I have managed to find a place in the industry.
However I am going to say that you are at an advantage in having come from an engineering background.
Could you be a developer in 3 months?
Maybe, it depends on how fast you learn and how well you will be able to persuade a prospective employer to hire you.
I would not however recommend going into software development to make money - you are never going to be paid for all those hours you put in outside of work, it's really more of a lifetime commitment than a job.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Start small - Eddie is right that a lot of the "boot camp" experiences are a rip off.
You could start for free to see if it makes any sense to you; if you mind works the right way.
Go here: Downloads | IDE, Code, & Team Foundation Server | Visual Studio[^] and grab a copy of the Community Edition (older versions than 2019 are available via the "older versions" link on that page if your hardware is relatively limited) - it's free and complete, as well as being the best IDE on the planet.
Then go here: .NET Book Zero by Charles Petzold[^] and grab a copy of the book.
Now start reading, and see if you can understand it. If you can, then it's worth considering a career in software. If you can't ...
Getting that job though; that'll be the hard part. Experience counts in this business - just as it does in architecture - so getting the first job may be a struggle.
Whatever happens, good luck - I hope it all works out for you.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
A few months is a short period... Especially when all you're doing is learning.
You'll really start learning out in the field.
Anyway, you'll need to get some basics covered before anyone would even consider hiring you.
Get some certificates to assess and prove your skills.
Also very good, write some blog posts to show you're really into it.
I'd apply for a junior job with low pay and then work your way up, then switch jobs and get paid what you're actually worth by that time (which is usually a lot more than you get from an intern/junior position).
Good programmers are hard to find, so the people willing to learn should get a chance.
I started working in IT from scratch, no previous experience.
I had a little help as my uncle bought my dad's company and so I could work there because of my connections.
After about half a year I became lead developer, which really says more about the skills of the company than about me.
Then again, I spent 8-9 hours programming on the job, I had a mentor, and I continued at home for another 4-5 hours every evening (I was still living at home and I had only a few minutes commute).
It's possible, but not easy and you need a bit of luck (and a lot of perseverance, I've been on the edge of quitting because I really didn't get the hang of it at first).
|
|
|
|
|
Sander Rossel wrote: and a lot of perseverance
Or plain stubborness.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
This thread is why I love CP. Just a treasure tomb of practical feedback with a bit of hot sauce tossed in from JSOP occasionally.
In reading, I agree with the others that your background will easily give you the practical knowledge to solve problems. You don't get an MS in Architecture without learning how to think creatively. Some of the best developers I've worked with have alternative degrees - music, math, physics. But, I think you need to be realistic and focus a bit. The boot camps might get you started, but in reality you're looking at 1-2 years of effort, probably more to the longer time period.
I underlined developer above (not programmer) to point out that we (developers) create applications to solve problems. As part of your learning process, you need to be looking for that moment when you say to yourself, "Dang, I get paid for this." And you're having fun. Obviously, you don't like architecture  There will also be times of intense frustration (as other's have mentioned above).
I happen to have an electrical engineering degree, and I love being close to hardware. In my senior year a long, long time ago, my project was to write a device driver for a daisy wheel printer using a parallel interface, and I was hooked. I've worked with missiles, test equipment, EW systems, GUI development for embedded systems, etc. Unless I am starving, I will never do anything web, and java script horrifies me.
So, if you pursue this interest, you'll find yourself learning a lot of different things (I STRONGLY recommend a class in data structures and algorithms once you get a few programming classes under your belt). Over time, you'll do projects that resonate with what you like. The other side of it is you'll get a really crappy assignment where you are paid a lot of money to overlook the crap.
Good luck. Oh, one other thought. As an alternative to "boot camps", go out to youtube and search for college classes that the universities are making available for free. I am routinely amazed at the amount of information available.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
m4444 wrote: if I can realistically self-teach myself programming in a few months,
Yes, I don't see why not if you have the aptitude. But note that "programming" is a bit like "knowing how to use a steering wheel". Just as knowing how to use a steering wheel isn't going to get you ready to race in the Indy 500, "knowing programming" is very unlikely to make you job-ready. It doesn't work that way. That being said, I encourage you to learn software engineering if you have the aptitude. It could lead to a very rewarding career and more happiness that you could probably imagine. No, really.
I urge you to read this Quora post:
Ravi Bhavnani's answer to "I want to start learning how to code. Where should I start? What do I need?[^]
/ravi
|
|
|
|
|
I can't use JSON for rendering a parse tree because JSON does not preserve the order of subelements and because of the way multiple values are presented it gives json problems.
XML can do it, because XML preserves element order and an element can be present more than once within its parent container.
But I don't want to bother if everyone hates XML.
What would you do?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
If XML is what you need use XML!
See your options and pick the best (optionally the 2 or 3 of them) and use it...
Neither JSON nor XML is rocket science... If using XML, just remember to provide a working schema...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
