EarthLink Non-Existent DNS redirection


Your spreading of your new program finally hit the DNS servers that I use on my EarthLink DSL. And at first blush it had all the appearances of browser hi-jacking.

So no matter how you paint it, you may not be technically "browser hi-jacking" but you accomplished the same thing.

Your blog claims you are doing this to enhance user experience. That's BS and you know it. The real motivation is ad/click revenue.

This feature is no different than when someone hacks a DNS server and repoints a domain.

The only acceptable course of action for EarthLink is to disable this "service" and issue an apology to users.

Are you getting a "removed by HIPS FW" ?

Are you not seeing things you normally would when you surf the web? When you view the html for the page do you see a comment that content was "removed by HIPS FW" ?

The answer is that CA's Firewall product is blocking them. It is configured out of the box to block banner ads. Well, sometimes what it identifies as a banner ad isn't. For instance this one:

To solve this problem, go to CA's Personal Firewall settings. Go to the Privacy group, then configure the Ad/Pop-Up blocker to not block banners.

CA settings pages that need to be updated As another person pointed out, you may also need to check out the Cookie Control advanced settings. I found that in order to get some sites to work properly, I had to allow the private header information to go out.

Extreme Programming: Science or Philosophy?

I am going to build this posting in an iterative fashion. So, don't be surprised if you see it show up again in your feed reader.

What makes something scientific? Provides a way that the hypothesis can be proven false.

Philosophy requires a paradigm shift. Until you are "enlightened" you just won't get it. You can't prove it wrong.

Kent's background and viewpoint.

Ron's background and viewpoint

My experience in spreading the word about XP practices has been primarily one of elightenment. There is a lightbulb that just clicks on when the other party "get's it".

Customer Proxy

When you don't have the customer handy, a good person to represent the customer is the trainer. In my experience, the organizations trainer has been in touch with the needs and practices of the workers. I've repeatedly heard and experienced that the training room is a place where the workers open up with ideas, thoughts and concerns about the software or processes.

Reflector for disassembly

This is a great free tool that let's you analyze, and decompile .Net assemblies in your choice of IL, VB or C#.

There are a number of plug-ins available too. Use Reflector in conjunction with the File Disassembler plug-in for recreating lost source code.

What does TEAM mean to you?

Some people use the word team to say that they work with other people together. For instance in the traditional big shop, the Architect works with the developers and testers. Everyone has their pigeon holed tasks.

In our small team, team means that anyone is capable of doing the job. While I may be responsible for overall direction as team lead, anyone can do all of the tasks. From working to manage the work, the needed documentation/status reports, business analysis, development and testing. This arrangement has been very beneficial for us in terms of integrating new people and coping while people are out a week at a time.

Because everyone can do the work doesn't mean there aren't specialities.  Quite the contrary.  A really good team will be a blend of people with different backgrounds, skills and strengths which complement each other.  A shared vision with a project that has been broken down into achievable goals helps to focus the team on the work.

Another very important aspect of the team is respectful communication and understanding.  Feedback is important. In a functional team the members let each other know when they are not understanding the other persons view or actions as well as when things are going well.  Don't delay the feedback.

XP Code Review

If it's good to do a code review, do it more frequently. This is one of the things that happens when you do pair programming. The code is continuously being reviewed by the pair. However, when you a have a very small team you probably won't have much "promiscuous pairing" going on. Then you can do a daily team code review. It won't take much time because you're only going over today's work not a whole release. Be sure to leave enough time to refactor too!

Spammer's domain name masquerading

It looks like my domain name has been picked up by some spammer's.

My domain name starts with an "early" letter and is nice and short, so it probably caught their attention.

Now, what's happening is that they are forging mail from my domain and submitting it through SMTP servers that aren't doing authentication. So now, I'm getting all sorts of bounced messages.

Seems to me that a couple of things could be done to help alleviate this sort of spamming:

  • All SMTP servers should require authentication
  • All SMTP servers should only take mail for their domains
  • Spam scanners should block messages that weren't submitted through a SMTP server that matches up with the domain name
  • Spam scanners should NOT return undeliverable messages, it just chews up more bandwidth.

Huddle 'round the projector

When it comes to doing a code review or project review, nothing beats huddling around the projector! Even with multiple monitors you can't get more than a couple people crowding in to see the material. Since we have a big white board we can just wipe it clean and connect a projector up to one of the computers video lines. Instant big screen code review in the development area! There's still enough open whiteboard to jot notes or mark up what's being displayed. Now if I could just get the big dogs to spring for a smart board!

I think it'd be awesome to pair (or mob program) using a dual or triple projector set up on a wall!

Interfaces are cool

I'm talking about OO interfaces. They came in handy recently when I was working on some code (Java) that launched a web browser as the result of a message that was received. In my test I was primarily concerned with the message I would receive back from that code.

So, the answer for me, was to extract the interface that I needed for the call to the web browser. Then I created a "mock" web browser that didn't do anything. So, when my tests are run the functional code around the call to the web browser is exercised and I don't have a bunch of open web browsers on my system.

You can do something similar if you are wanting to do some processing on the content received from a web page. Actually going out to the internet and pulling information is an expensive operation. Instead you can create a "mock" web browser class that has hard coded the expected web responses.

I've also been working on some C# code that involves communication between applications. By using an interface specification for the communications layer I can swap out the communications layer at will. For testing I'm using a mock object that implements the interface. Now I'm able to experiment with a variety of technologies for implementing the communications layer and I can choose the one that works best. Or I'll be able to choose the one that works best for a given situation. Definately cool stuff.

In summary, interfaces are a useful tool to keep in your bag of TDD tools.

Crystal Reports and TDD

It is my experience that doing TDD (test driven development) could help avoid some pain with Crystal Reports. Suppose that you have a column of floating point numbers that go out to 6 places. You want to display those numbers to the user rounded to 2 places. Then you are going to display the sum of the numbers displayed. This is where the fun comes in. It was our experience that the sum being displayed is the sum of the unrounded numbers that was then rounded to 2 places. This is entirely different than rounding first and then summing.

So what is the answer? The answer is in the pink book. TDD of the presentation layer is tough. Keep the presentation layer thin. TDD the business logic that puts together the numbers that will be displayed, include the rounding and summing. Pass a dataset or multiple datasets with the data to your Crystal Report. Now your presentation layer is thin and doesn't have to know anything about where the data came from. (No redirecting of databases at run time!)

My XP Team's progress

A recent topic of discussion in the XP2E yahoo group got me thinking a little bit about the progress our team has made in adopting XP, some of the issues we're encountering and where we're going.

We've read the XP2E book as a team and are following on with the XP Installed book. The XP2E book helped us with a lot of the theory and we started down the road together. With the Installed book we're picking up some more "how to do it" material.

  • We've physically opened up our area and are enjoying the improved communication.
  • We're pairing up most of the time. We notice when we don't (more errors and slower).
  • We're holding each other accountable to standards.
  • We are still building our TDD, program by intention skills.
  • We are getting a lot more user involvement, but not co-located.
  • We are having few (near zero) minor defects found in production.
  • We're still getting a handle on stories and points.
  • We're working out issues with testing and data bound controls.
  • We're having problems with integration - we need to install a CI server.
  • We're looking to swap out VSS for SubVersion.
  • We are going to work on picking up design patterns soon.

And as always, how do I test this object that is generated by the ORM tool and expects to see a database on the back end?

This week we moved 3 releases (different projects) to production. All of them sailed through testing with no defects. We have 1 more system pending release and 2 more in testing. Overall, a pretty good feeling.

The weekly planning and keeping focus on those goals is an extremely important thing for our team. The morning stand up helps us to keep our focus.