Phone Line Scam

I was bored waiting in an airport so I researched some of the spam messages that certain family members feel compelled to forward. This particular message was about a phishing attack:

Date: Monday, March 15, 2010, 9:50 PM

90# on your telephone

I dialed '0', to check this out, asked the operator, who confirmed that this was correct so please pass it on ...
(l also checked out Snopes.com. This is true, and also applies to cell phones!)

PASS ON TO EVERYONE YOU KNOW
I received a telephone call last evening from an individual identifying himself as an AT&T Service Technician (could also be Telus) who was conducting a test on the telephone lines. He stated that to complete the test I should touch nine(9), zero(0), the pound sign (#), and then hang up. Luckily, I was suspicious and refused.

Upon contacting the telephone company, I was informed that by pushing 90#, you give the requesting individual full access to your telephone line, which enables them to place long distance calls billed to your home phone number.

I was further informed that this scam has been originating from many local jails/prisons DO NOT press 90# for ANYONE.

The GTE Security Department requested that I share this information with EVERYONE I KNOW.

After checking with Verizon they also said it was true, so do not dial 90# for anyone !!!!!

PLEASE HIT THAT FORWARD BUTTON AND PASS THIS ON TO EVERYONE YOU KNOW!!! We need to protect one another from these scams. Don't expect the phone companies to alert you to this danger.

A quick search shows there isn't anything to worry about unless your on old equipment that is poorly configured. For additional information see:

• FCC
• Snopes
• Jonathan de Boyne Pollard's page (good description of the original problem that spawned the hoax)

However, this hoax is based on an interesting exploit. A PABX can be configured to allow call forwarding to connect two outside lines. The actual sequence would be R90#. The R or recall is to notify the PBX that you want to do something such as dial out. The 9 indicates you want to dial an outside line and 0 is the number for the operator. Finally # connects the original call to the new number dialed.

Acceptance of Evolution by State

There is a well known chart showing the public acceptance of evolution in 34 countries. The United States was second to last. Thus far, I have been unable to find a similar chart showing a breakdown of the acceptance of evolution by state. Looking around though I did find a freely available data set that has the raw information. The Pew Forum's U.S. Religious Landscape Survey has the question:

Q.10c Evolution is the best explanation for the origins of human life on earth

RESPONSE CATEGORIES:

1. Completely agree
2. Mostly agree
3. Mostly disagree
4. Completely disagree
5. Don't know/Refused (VOL.)

But, Eclipse makes it easy...

Charles Petzold has nice article titled Does Visual Studio Rot the Mind?. I was thinking about this article when doing a code review and frequently getting the excuse that the awful code was ok because "Eclipse makes it easy." The following snippet shows some of the problems:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

package example; import java.util.List; import scala.actors.threadpool.Arrays; /** * Immutable class for ... */ public class Example { private List<String> mData; private int mCount; public Example(String[] data, int count) { mData = Arrays.asList(data); mCount = count; } public String[] getmData() { return mData.toArray(new String[mData.size()]); } public void setmData(String[] mData) { this.mData = Arrays.asList(mData); } public int getmCount() { return mCount; } public void setmCount(int mCount) { this.mCount = mCount; } }

Here is a brief look at some of the questions and responses.

• Why do the accessor/mutator method names have the "m" prefix (by convention our code uses a prefix of "m" on member variable names, but it shouldn't be reflected on the accessor methods)?

  Eclipse generated the setters/getters. It makes it easy to generate them this way.

• The comments say the class is immutable, why are there mutator methods?

  Eclipse generated the setters/getters.

• The class is not immutable.

  Then why would Eclipse generate the setters?

• Why are you using scala.actors.threadpool.Arrays instead of java.util.Arrays?

  Eclipse generated the imports.

It was clear from his answers that he barely looked at the actual code. Eclipse enabled him to cobble together some crap that compiled without really knowing what he was doing. This is not really the problem with the IDE, idiots can write code without the aid of an IDE. What really surprised me is another senior developer on the team supposedly reviewed the code and found nothing wrong. When I asked what he checked the reply was "I brought it up in Eclipse and didn't see any warnings or errors flagged on the code."

Web Services and the Law of Standards

I was recently asked why SOAP, WSDL, UDDI, and the various WS-* specifcations are fairly uncommon in practice compared to simple REST interfaces. Personally I think this is another example of John F. Sowa's Law of Standards. The basic statement is:

Whenever a major organization develops a new system as an official standard for X, the primary result is the widespread adoption of some simpler system as a de facto standard for X.

A quick look at some big online companies seems to confirm this:

Amazon:

I was recently talking with Jeff Barr, creator of syndic8 and now Amazon's chief web services evangelist. He let drop an interesting tidbit. Amazon has both SOAP and REST interfaces to their web services, and 85% of their usage is of the REST interface. Despite all of the corporate hype over the SOAP stack, this is pretty compelling evidence that developers like the simpler REST approach. (I know there are many more complex applications where SOAP is better, but I've always liked technologies that have low barriers to entry and grassroots adoption, and simple XML over HTTP approach seems to have that winning combination.)

Google:

Finally, we'd like to bid a fond adieu to one of our first developer products, the venerable SOAP Search API. It has been deprecated since 2006, when we stopped accepting new developers for the API, and it's finally hanging up the gloves and retiring on August 31st. It has been steadily declining in usage over the last couple years and we believe that the majority of use cases are sufficiently handled by the more comprehensive AJAX Search API (which supports not only web search, but local, news, images, video, and more). For those interested in migrating, there are more details in the AJAX APIs blog.

Yahoo!:

Q: Does Yahoo! plan to support SOAP?
Not at this time. We may provide SOAP interfaces in the future, if there is significant demand. We believe REST has a lower barrier to entry, is easier to use than SOAP, and is entirely sufficient for these services.

Finding the Location of Perl Modules

There are (at least) two simple ways of finding the location on the file system of a perl module. The first is to use the perldoc command.

$ perldoc -l CPAN
/usr/lib/perl5/5.8.5/CPAN.pm
$ perldoc -l Pod::Perldoc
No documentation found for "Pod::Perldoc".

The second way is more robust, but also a little more verbose. Just use a perl one liner that uses the module and then looks up the path in the %INC variable.

$ perl -MCPAN -e 'print $INC{"CPAN.pm"}, "\n"'
/usr/lib/perl5/5.8.5/CPAN.pm
$ perl -MPod::Perldoc -e 'print $INC{"Pod/Perldoc.pm"}, "\n"'
/usr/lib/perl5/5.8.5/Pod/Perldoc.pm