IT/Software career thread: Invert binary trees for dollars.

Vinen

God is dead
2,788
494
Are you guys getting bought by Dell?
Good luck!!
Fuck who knows. This rumor looks more credible then the last but VMware being the mix (company I work for) definitely throws the entire EMC/Dell merger into what the fuck realm.

I'd love to see who will help them raise the capitol for this.
 

Vinen

God is dead
2,788
494
Well it happened this morning.

I'm looking for a new job..
I'm still in a good position here. Going to wait and see where the stock is in a few months. It's no longer feeling like the handcuffs it once was.
Hope you had some EMC stock-
 

taebin

Same trailer, different park
973
450
We're doing pretty well over here at VCE. Watching Tuchi / Dell / Goulden is awkward as shit.
 

Tenks

Bronze Knight of the Realm
14,163
606
People that write XML reading/parsing as just raw strings and substrings grinds my gears. I can understand it if you're doing non-complex operations on the document but dear lord I was asked to just extend this service by a little bit and I'm going to have to basically rewrite the entire thing because they don't DOM the document despite reading and updating nodes. So the service currently can't handle updating the document if multiple nodes of the same name exist, it can't perform complex matching, it can't reliably add new nodes to the document. Luckily since I'm in here gutting it anyways I'm getting a ton of "Oh good you're finally doing that? It needs to do this as well." requirements from people since no one wanted to take the time to actually fix the damn thing.

And despite my love/hate relationship with Groovy ... god damn does it make working on XML easy
 

Cad

scientia potentia est
<Bronze Donator>
25,018
47,105
People that write XML reading/parsing as just raw strings and substrings grinds my gears. I can understand it if you're doing non-complex operations on the document but dear lord I was asked to just extend this service by a little bit and I'm going to have to basically rewrite the entire thing because they don't DOM the document despite reading and updating nodes. So the service currently can't handle updating the document if multiple nodes of the same name exist, it can't perform complex matching, it can't reliably add new nodes to the document. Luckily since I'm in here gutting it anyways I'm getting a ton of "Oh good you're finally doing that? It needs to do this as well." requirements from people since no one wanted to take the time to actually fix the damn thing.

And despite my love/hate relationship with Groovy ... god damn does it make working on XML easy
Parsing XML manually is so 1999
 

Tenks

Bronze Knight of the Realm
14,163
606
Parsing XML manually is so 1999
Its shockingly common in the Hadoop ecosystem. Since you process hundreds of millions of documents if you can avoid DOM'ing the object it really does speed up your job executions. But the problem is people tend to not understand where that demarcation lies with "Should I string parse or should I use an actual XML parser?"
 

Cad

scientia potentia est
<Bronze Donator>
25,018
47,105
Its shockingly common in the Hadoop ecosystem. Since you process hundreds of millions of documents if you can avoid DOM'ing the object it really does speed up your job executions. But the problem is people tend to not understand where that demarcation lies with "Should I string parse or should I use an actual XML parser?"
If you're processing that many docs, my thought would be whatever accumulated errors you're going to get by trying to manually parse XML overshadows the savings. Because if you're not just looking for something quick in the file, you'll probably create a quick library to help you parse certain things, then you extend it a little here and there to do things you come up with... pretty soon you've written and are maintaining your own half assed XML parser. Seems better to avoid the errors by using a commercial XML parser and just configure it the way you want for the speed/depth you need rather than trying to half ass it.

I get it that it'd be application dependent but I'd have trouble coming up with a use case where just string parsing makes sense?
 

Tenks

Bronze Knight of the Realm
14,163
606
My rule of thumb is for reading I just string parse if I'm updating then I switch to a full XML parser. If I can get away with just getting what I need from like StringUtils.substringBetween(str, "<jobStatus>","</jobStatus>") I'm not going to pay the overhead to load that up into a SAX parser. But the issue I'm running into is the XML is more free-form and I don't always know what I need to get and/or update underneath the document (I know I need to go three levels deep but the tag names are user input) so I simply have to use some form of xpath engine.
 

moontayle

Golden Squire
4,302
165
We use XML for data needed to run our front end. I was running a proof of concept to gather data and update the display accordingly and ended up setting up something like 20+ POJO classes, a couple of them something like 5-6 tags deep. It's kind of silly but it has to be done this way to get the data we need.
 

ShakyJake

<Donor>
7,847
19,714
People that write XML reading/parsing as just raw strings and substrings grinds my gears.
Unless it's not a well-formed XML doc, I usually write serializable classes that serialize into XML. Way easier to work with object properties than screwing around with elements and attributes.