|
… and whose least circuits you are unworthy to design. 
(With apologies to Douglas Adams)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
|
Electric sheep?
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
|
You were just temporarily disconnected from the Matrix.
We expect no further disruptions and we apologize for any inconveniences.
|
|
|
|
|
As popular demand was crying out for "our own NuGet server", I thought TeamCity 2019 would be the obvious choice for this as it has a built-in NuGet server capability.
After more than a day I managed to get it working for our own built artifacts, but then was puzzled by how to host other .nupkg files on it.
No mention on the TeamCity website how to do this, only after much digging on the internet I found this:
Quote: But I guess it's clear that Team City at the moment doesn't offers full NuGet server capabilities which can be used to establish company's local repository
Add existing nuget package to the feed – TeamCity Support | JetBrains[^]
Grrrrr 
|
|
|
|
|
|
So I have to make this SOAP (1.1) service so some third party application can connect with our system and request data.
Fine, just tell me what the SOAP service should look like.
So I get a WSDL, which is invalid because two types with the same name have the same namespace (x3).
So I get a new WSDL and right after that a third because the other wasn't correct, which, after testing with the third party application (which I don't have myself), turns out to be incorrect because the namespaces don't match.
And I go back to the old WSDL, which still has the same type names.
I've just implemented the fifth WSDL with XSD's and I have no idea if this is going to work or not.
The version of the WSDL is embedded in the namespace, but apparently it's not possible to just give me that version of the WSDL.
I'm getting different versions in the namespaces, but I just changed the version to match that of the third party application and hope it'll work when I can test this stuff again.
The best part is that this is apparently a standard that's maintained by a work group and I'm the third person to implement this standard (about 10 years after the last implementation) 
|
|
|
|
|
Ha! XML! It was all the rage back in 1999! 
|
|
|
|
|
The standard message I had to implement pretty much predates the internet (and I guess XML as well) 
Here's a two line example.
DN1400150015090337000150024010001500250200015002305000150906010001509070900015001901000150021060001500460100015210101000152102010001500280100015002904100150032010001500360310015003802000150104010001500350310015003403100150304060
VN1400152019053100000001230491000011000938127???0000110009381272938127020011890580A E6181581 Now imagine having 100s of lines
(There may be some personal data in there, but I think it's safe to share  )
The SOAP service is just so we can exchange these kinds of messages.
You can imagine XML is actually the lesser of evils
|
|
|
|
|
XML to transport binary data? Oh, The Wonderful!
|
|
|
|
|
It's not binary, those are actual values (seriously)!
For example, the "A " somewhere at the end of the second line means quality A (the space is there because AA is also a possible quality, so that's two reserved characters).
The meaning can be deduced from the upper line, which is the definition and has codes with field length and precision.
Awesome that people created a standard that's so cryptic people actually think it's binary
|
|
|
|
|
Um, forgive me if I'm wrong, but isn't one of the main points of XML to break down strings like that into individual data items?
So instead of a single line of hundreds of characters, you have at least three lines for each group of zero to five characters. It's what XML fanboys call "human readable" and "far superior to CSV".
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Yeah, the message itself isn't XML, it actually predates XML.
The only thing that's XML is the (EDI) SOAP service that communicates the messages.
The service has a few functions, like requesting a list of all messages (without content), requesting a single message (with content), updating the message status and sending a message for others to pick up.
It's pretty difficult to generate that service if I can't get a proper WSDL though
We're building the SOAP service so that any customer with a specific application (which are quite a few) can receive messages automatically.
The only alternative is to take a subscription elsewhere, send them our data (in another simpler format) and they do the communication.
The subscription is fine for smaller businesses, but gets very expensive when you have lots of customers.
We also have customers who download the message manually (from a website or from an email) and then manually input the file into the application.
This industry isn't known for their modern take on IT
I know that the work group that maintains the message format also wants to move forward to XML or even JSON, so that would be a welcome change, but as long as the current message works no one wants to pay for that.
|
|
|
|
|
|
Oh, I'm very familiar with EDI.
Not only because I used it decades ago, but because of a recent contract (which lasted literally more than ten times longer than I was originally contracted for) which involved equipment used in airports -- so any new technology had to be cleared by roughly 9,785,276 governments, before it could be deployed.
EDI was just the tip of the iceberg. Anyone remember the fifty flavours of serial data? DOSKEY and DOS batch-script syntax?
Think you know everything because you can plug in an Ethernet cable? Think again, and get your soldering iron out.
Of course, I remembered pretty much nothing about the old tech, because I hadn't used it for somewhat more than a few weeks (which is about the limit of my memory), but relearning is a damned sight quicker than learning for the first time (especially if you have no frames of reference for it), so it was a job where kiddies need not apply.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Hey, if they like old stuff, talk them into using PostScript, which does the job of XML but a thousand times better!
XML is like PostScript that's had its bollocks chopped off; kiddies only revere XML because they haven't used PostScript (and, of course, because it was "The Next Big Thing!", for a while).
And no, PostScript has nothing to do with adobe.
It was adobe's effing about (in their creation of Pee-Defecated-Files) that led to so many people abandoning PostScript, because they somehow managed to make it look hideously inefficient and slow, which it Shirley ain't.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I uhhh... might stick to regular XML 
And we don't actually like the old stuff, we're just forced to use it 
|
|
|
|
|
Where on earth did you get my phone number from?
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!
|
|
|
|
|
|
wow. someone designed that on a bender.
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.
|
|
|
|
|
No doubt evil witchery was involved 
|
|
|
|
|
that's some hackneyed magic there. looks like it was designed by someone with a grudge against their employer. LOL
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.
|
|
|
|
|
honey the monster, codewitch wrote: looks like it was designed by someone with a grudge against their employer humanity
FTFY
|
|
|
|
|
Looking good! 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
