Mwave.com: issue resolved? Who am I kidding?

You just can’t make this stuff up: my WTF/hour factor has overflowed.  Here’s a partly-redacted letter I’ve posted to Mwave.coms general manager; images have been removed to protect the innocent.

The bottom line is that Mwave.com is completely disconnected from reality–and NewEgg.com usually offers lower prices and free shipping…shame on me!

Without further ado…

Mwave.com: issue resolved

I have had an awful time with Mwave.com when an order was held up due to a discrepancy with my “billing telephone number”.  After sending a dilithium-crystal-powered poison pen letter to the general manager, the customer service supervisor, Maricela, was authorized to resolve the situation and we did.

It seems they have a lot of stupid processes and it seems that their systems are very bad.  The hangup was confirming my billing credit card number on the order (which was intentionally bogus) matched the telephone number on my credit card.  I don’t believe states allow that (privacy considerations), and considering my bill-to, ship-to, and credit card addresses were the same, the extra step seems stupid.  The explanation is that bad guys will hover and scoop up the package from the delivery guy “every now and then.”

One open issue is how Mwave.com was able to verify the billing telephone number.  I have to figure out if this is an American Express or Bank of America problem.  In either case, I believe privacy laws prohibit this information from being required to complete an on-line transaction.

So, let’s think about this.  How does my credit card having the same telephone number as what’s on the ”bogus” order prevent the bad guy from grabbing the goods?  Unless Mwave.com calls me to confirm it’s a valid order, which they have not mentioned doing, the answer is, not a damn thing.  Mwave.com, being faced with an occasional problem of this sort, is using a shotgun to hammer in a thumbtack: they’re using the wrong size of the wrong tool.

Instead, Mwave.com should require the carriers to confirm the recipient’s with picture ID when delivering a high-value shipment.  UPS (their current carrier), would throw your box of disk drives out of a moving truck if they thought they could hit your doorstep (if the box landed in the rain, they’d be okay, as long as it was on your doorstep).  OTOH, FedEx Home Delivery used to deliver wine to me, and their driver would actually ring the doorbell and confirm I was old enough to sign for the package.  Or, if you live in an area where porch pirates are virtually unknown, Mwave.com should include a provision allowing leaving the package (which would clear the carrier of any liability).

When my order got stuck in the unapproved queue, I didn’t receive any notice that it was pending.  And I’m still deeply concerned that my credit card was charged before they shipped the order–yes, that’s right.  My AmEx shows a charge on Sunday, 12/27 for the full amount.  And they’re a 9-to-5 operation, too–definitely out of touch with reality.

Let’s see what UPS does to the shipment–I can’t wait.

OOP for the AS/400 developer: introduction to OOP

What is OOP and why is it important?

It’s “object-oriented programming” and it’s a different way of thinking about developing, supporting, and extending applications.  C#, Visual Basic, and Java are three of the best-known OO languages.

There are a number of new concepts in OOP, including inheritance, abstraction, encapsulation, and polymorphism.  At risk of upsetting the purists, these concepts aren’t required for every OO program.  They offer an extremely powerful way to share, override, and extend previously-written code, so a well-designed OO application becomes relatively easy to enhance and extend.  On the other hand, a poorly-written OO application can turn into a nightmare, not just from the code itself, but from poor use of the concepts mentioned above.  OOP enables both “spaghetti code” and “spaghetti apps.”

In the AS/400, we use “procedural programming” methodology, where we ”do things” to data.  Most AS/400 developers use ILE RPG to specify a series of steps to perform a task, which could be anything from updating a customer’s receivables balance to changing the status of an order.  Each step usually consists of an operations code (think “verb”: ADD, EVAL, CHAIN) and one or more data elements. 

Object-oriented programming is about objects (think “nouns”).  Using the OOP term “class” to define an object, what sets OOP apart from procedural programming is that a class defines a “thing” (a customer or an order) in two categories: the data itself and what can be done to that data.  The OOP focus is on the thing, not on the action.  

For the sake of this discussion, ignore the “database” concept–the point of the database is to persist (save) the data over time, so when we talk about the class “Customer”, we’ll assume the data for the specific customer has been made available.  So, our Customer class will contain its data members (data fields) and methods (update outstanding balance, delete, change status).  So, to update a customer’s balance, the code might look something like this:

Customer.UpdateBalance(OrderAmount);

 This code says, “Pass the ‘OrderAmount’ into the ‘UpdateBalance’ method in the ‘Customer’ class and execute the method.”

When developing an OO application, the first steps include defining objects (customer and orders) and defining what actions will be taken on each object.  So, it’s fair to say that more front-end design work is helpful (but not necessary) in an OO application. 

One way to understand the “Customer” class is considering it as a combination of the database record(s) and at every program that modifies the customer database.  In reality (a useful concept even in the OOP world),  there would be more than one class defining a customer.  Name/address, contact information, and history are a couple of possible classes each defining a specific concept of the customer.   

 Because classes are self-contained, it becomes very easy to enhance an application by adding a class with a new capability and then referencing that class.

How does this translate into the AS/400 environment?  Well, it doesn’t, really, but one weak analogy for a class is a service program with local variables and multiple procedures that modify those variables.  In OOP, though, a programmer has the ability to execute a method defined within the class without the execution thread being within the class.  A class is a container for the data elements and all the actions (methods) that are valid for those data elements, and all of those “members” (the term for the elements that comprise the class) may be externally accessible. 

An aspect of OOP overlooked by procedural programmers is its ability to support rigorous automated testing.  When the code that updates the customer file is spread over dozens (or hundreds) of programs, testing is nearly impossible.  But when the code is centralized in a couple of classes, it’ easy to write test scripts that test every method in a class, without requiring database or manual user interface (UI) activity (a “best practice” for AS/400 developers is to write a test program for every service program).  Whenever a class (or service program) is changed, part of the quality assurance process is to execute the test program and to confirm the results are as expected.