HUH? Do You Understand This?

[buyologist-3]

 Found this today and the verbage has me stumped!  Is it just information, or, something else?

"Three are the basic instrumentations that eBay has implemented to force invoked methods to show faulty behavior: blocking or interrupting the method logic, for example by throwing an exception; changing the state of methods, for example altering the return of response.getStatusCode(); and replacing the value of method parameters, which consists in modifying the value of an argument sent to a method.

To implement the above three types of instrumentation, we have created a Java agent. In the agent, we have implemented a classloader which will instrument the code of the methods leveraged in the application code. We also created an annotation to indicate which method will be instrumented and put the instrumentation logic in the methods annotated.

In addition, eBay engineers also implemented a configuration management system to dynamically change how fault injection behaves at runtime. In particular, for each endpoint supported by the eBay app, engineers can alter a number or parameters to test specific behaviors."

There's more, but this is a nice cross-section.  Any ideas as to the translation? www.infoq.com/news/2022/12/eBay-fault-injection-instrument/   

Found at that site.  infoQ.

Thanks!

[ckimodog]

@buyologist-3 

Lots of adjectives.  Looks like some of the spam we see here first thing in the morning.  I'm stumped as well.  😐

Happy New Year. 

[spark-chaser1]

Doesn't appear to be legitimate. I wouldn't click on any links attached to anything that read like that.

[southern*sweet*tea]

That's not just word salad, it's a high class word salad.

[my-cottage-books-and-antiques]

It's computer talk. Nothing I need to really know about as a seller. 

[a_c_green]

---

@buyologist-3 wrote:

There's more, but this is a nice cross-section.  Any ideas as to the translation?

---

It's a discussion about exception handling or error handling, what the eBay software is supposed to do when Something Bad happens. When you're writing code, you need to account for what to do when something goes wrong, not just write out a linear path for what needs to be done if everything goes perfectly.

Generally, for each command you issue in your code, you need to have a plan (or a pre-written handler) for what to do if your command fails in some manner. I have to admit that I was sometimes amazed to see a returned error message in my own code for some basic thing that I never in a million years thought would fail... but just did. 🙄

In a general sense, I'm kind of happy to see that excerpt of discussion, because it means that eBay might just be taking Quality Control a bit more seriously now, and might be trying to test and peer-review their code much more than they have in the past. The quality of the code being released to Production in the past has sometimes been atrocious, with those of us having backgrounds in IT sitting here and wondering, "What were they thinking?"

To this day, I can think of various dumb mistakes in their coding that I have learned to work around or ignore, such as the screenshot below, in the same manner that eBay has been ignoring them as well. Maybe things will get better. Maybe they won't.

Sale that supposedly shipped one day before it was sold

[Anonymous]

Of course, we do and someday it will quietly disappear as quickly as it rolled out. Unsustainably progressive gobbledygook which can be understood to mean ((whatever is necessary)), until the intentional charade and its proxy defenders are proverbially sacrificed and kicked under the bus in broad on main street.

[Anonymous]

...in broad daylight, on main street.

edit

[pburn]

Sometimes the essence of a comment is obscured by the desire to be erudite or clever. Especially when it misses the mark.

Thank you for your understanding.

[albertabrightalberta]

That site is registered in Germany and they have a "joker DOT com" email address. Coincidence? 

I'm guessing they used some type of translation software to come up with the gobbledegook. 

[Anonymous]

See sellers run.

[retro_entertainment_collectibles]

---

@a_c_green wrote:

---

@buyologist-3 wrote:

There's more, but this is a nice cross-section.  Any ideas as to the translation?

---

It's a discussion about exception handling or error handling, what the eBay software is supposed to do when Something Bad happens. When you're writing code, you need to account for what to do when something goes wrong, not just write out a linear path for what needs to be done if everything goes perfectly.

Generally, for each command you issue in your code, you need to have a plan (or a pre-written handler) for what to do if your command fails in some manner. I have to admit that I was sometimes amazed to see a returned error message in my own code for some basic thing that I never in a million years thought would fail... but just did. 🙄

In a general sense, I'm kind of happy to see that excerpt of discussion, because it means that eBay might just be taking Quality Control a bit more seriously now, and might be trying to test and peer-review their code much more than they have in the past. The quality of the code being released to Production in the past has sometimes been atrocious, with those of us having backgrounds in IT sitting here and wondering, "What were they thinking?"

To this day, I can think of various dumb mistakes in their coding that I have learned to work around or ignore, such as the screenshot below, in the same manner that eBay has been ignoring them as well. Maybe things will get better. Maybe they won't.

---

Exception/fault handling and testing thereof is generally among the most painful portions of programming.

Many moons back I worked with many game publishers porting code etc.  When Atari's 68000 based machines hit the market I was among the first to get a development system, CPU, Paper White and Color Monitor and even a whopping 20 Megabyte SCSI hard drive.  Woo hoo!  The C compiler was just yuck but I was versed on 8080, 650x and 68x00 Assembler.  Anyway's, me and two other fella's coded up the first plug in physical cartridge for the system, bunch a desktop accessories aka: McMacMcLike McDo!

So my portions were all 68K Assembler, Cartridge boot code, Print Spooler and UI etc.  All the Interrupt service routines since the app's needed to task against which only the Desktop and back early in the OS Development the hardware service routines did.  We' had horrible times for example with the keyboard buffering having to snatch whatever was in the buffer prior to any of the desk accessories usage or inputs to our desktop's accessories would fry the buffer adding to it, overflowing it then over writing it.  It was all done via pointer arithmetic inside the systems interrupt service code.  Not like Windows whereby one can attach and/or disattach from the ISR vector chains.  If you remember that was even an issue in Windows, people install a virus scanner for example or firewall etc and those obviously need hook and vector the CPU to ISR Code looking for malicious things coming into say the LAN port.  Used to be some of the vector chains once one inserted their own ISR vector it could not be removed.  So you remove McAfee AV but guess what, there's a bunch of it still laying around that just could not be removed as there was no way to recreate the chain that had existed prior to insertion of the new ISR vector being inserted.

In the Atari ST days was none of that...  You hooked by taking over the entire interrupt and then you're code had to volley the processing of the chain nor was there a way to reestablish the old one!  So anything go kooky system just lock up tight as drum and there were no system debug monitor apps, but even if there were they'd locked too.  So debugging?  OH MY GOSH!

Anyways... We were readying the product be shown at a trade show, the BIG BIG BIG Anticipated release!  Imagine desktop accessories like the Mac but better all sitting in a ROM cartridge!  The first one for the system!

48 hours before we are to head out my brother comes over, he coded for the Commodore Amiga platform, same CPU, MUCH better C compiler.  I tell him, hey all set to go!  He asks did you fully debug it?  Yep!  We're good...

Doesn't he just walk up to my machine and just starts mashing the keys fast and lo' and behold thing locks up tight as a drum!  I burned the midnight and daylight oil having to recode all the assembler dealing with keyboard ISR.  Given the timeframes we'd no time to ROM the code and test it.  So, we decided to run it off the hard disk at the show and just put the cartridge in the slot... BINGO.

Doesnt some young kid walk up, pull the cartridge out of the machine and there the desktop accessories are still running.  OH MY GOSH!

We managed get away with it but some of the other developers were like "Yea boy!  Nice!"

Later that night we're in the Hotel room, ordered a Pizza be delivered.  Knock on the door and other developers intercepted our Pizza and took one piece out and replaced it with Lime Jello.  Ha!

[buyologist-3]

Are you SURE?  I'm not.