Another attempt at fixing the fan belt throwing motorhome

I hope to someday to someday fill out the background on the prior adventures on the RV but it's a lot easier to start with today and keep current while eventually filling in past events as I can instead of starting from the very beginning.

From day one this RV has been throwing one of the three fan belts on the engine. It just happened again on the way back from a weekend trip. I asked for some help on RV.net. This is a slight rewrite of that adventure.

This is the contents of that post:

Short version: How do I get melted fan belt stuff off of fan belt pulleys? Chemicals? Elves? Fire? Nuclear Weapons?

Specifics:
1982 Beaver Catalina
P30 Chassis
Chevy 454

I keep throwing a fan belt in my RV. The same one every time; which is the front one that includes the fan, alternator, crank shaft, and smog pump. The alternator and smog pump turn freely so I think those being stuck are not the current issue. However, because of the buildup on the smog pump pulley I'm guessing that it got stuck once and is the root of the problem. 

I can't be sure why it started throwing belts as it did it before I got the RV. It's on the third, or forth, belt since I got it about 500+ miles ago. It was throwing the belt after ten minutes or so and then I noticed a huge buildup of melted rubber on the pulleys. Especially the smog pump pulley. I cleaned them off pretty well and it lasted the past 400 miles. When I checked it today there is a bunch of what I think is rubber in the bottom of the V of the pulley. 

Yesterday, on the way home from our weekend trip another one broke. It was after dark plus cold and damp so I had the lights on, heater fan on all the way and a fan blowing on the windshield to keep the fog off of it. We stopped for some Pho not far from home and then about two miles down the road I heard the belt snap and saw the voltage drop to about 12v. Knowing what the problem was I shut off the heat and fan and just kept going. Made it home without further incident. I'm pretty sure that the belt got hot because of the extra load and then stuck because of the pause to get our dinner.

** The reason I even ended up with this particular RV was that it died in the middle of the road right next to my uncles shop. It had overheated and was blowing steam all over the place. (That and a transmission stuck in first gear made it un-drive-able) It was a trade-in and the salesman was attempting to return to the dealership after delivering the new on. Long story short, my father made a great deal on it and now I co-own an antique RV that people accuse me of using to cook meth in. :)

Thanks for the help.

I got a lot of good advice in the responses. This is what I ended up doing:

Well, I fixed it for now. Much thanks for all the advice and general input.

Medium story short:
I took off the smog pump pulley and cleaned off the rubber melted onto it with a propane torch, a putty knife, a wire brush and a final cleanup with acetone. It was pretty clean looking when I got done. I (gently) put it in a vice to hold it. I put the original length belt back on it. Drove it at night for two hours with several stops and shut downs without a failure.

Long version: 
I keep the RV at a friends house and I was supposed to meet him at his place at 5pm or so to put it away. I started working on the belt at 3pm. I was having a tough time trying to clean it while on the engine. I recalled someone somewhere saying it was pretty easy to take off the pulley so I went for it. Three bolts but none of my standard wrenches fit. Trip back to the garage to get my metric set. Just like someone had said, 10mm fit. D**n pully was spinning like crazy so I put the belt on and tightened it to hold the pulley. A few minutes later I had it off without dropping one bolt. (Small victories) 

I tried to us a utility knife on it while holding it by hand when I got this clear picture in my mind of the knife slipping into my hand. I took it in the garage and put it in the vice. My propane torch is in a drawer right there next to the vice So, per a recommendation I found on the web, I gave it a try. Took a couple of minutes with the heat to get the bulk of the rubber off with a putty knife and then a few minutes more with a wire brush to get it really clean. A wipe down in the grove with some acetone and it looked pretty good. It even shined when I had it back on the pump and the flashlight was on it.

Back in the RV I spun the pump so a bolt hole was on the very top and then aligned a hole on the pulley with that hole. Got it the first time! A few minutes later and it was finger tight. I threw on the belt again and started the engine. No squeak and it did fall off after a couple of revs. Dog house cover on and I was on the road. (No cleanup if I was going to get there by 5pm)

I left the house at exactly 4pm. One stop on the way to get a fancy replacement belt I had ordered and another stop for an errand for my wife. WHERE THE HECK DID ALL THIS TRAFFIC COME FROM?! I haven't mentioned that I get flex time at my job so I don't normally travel during regular commute times and I normally commute against the normal traffic flow. That and working from home sometimes leaves me unaware of just how many cars normal people have to put up with.

Half an hour later I'm about six or seven miles down the road. I'd heard a squeak or two that eventually turned into a regular repeating squeak squeak squeak. (Those paying attention know what this is) The bolts on the pulley were only finger tight. I had forgotten to tighten them after putting on the belt. I pulled off on a wide shoulder and got to doing that. It is amazing how fast things get hot in an engine bay. The smog pump pulley wasn't that hot but the one on the alternator left red marks on my arm. A few minutes later and I'm back in traffic.

I skipped the pickup of the fancy (read $27 vs. $7) belt in hopes I could make the pickup for the wife. I made the wife's pickup just in time and finally made it to my friends house at 6:03pm.

I'm going to try and figure out how long of a belt to get for bypassing the smog pump and put one of those and another full length spare in the trunk. That and I will start bringing my metric tools with me when we take it out.

Starting the internship and Embracing the Suck

I just wrote up the first salvo in the Battle of the Internship. I hope this one does better than the last one. I haven't sent it yet. I'm letting it sit for a spell after which I'll review it and send it along.

The Battle of the Internship is where I put to work the stuff I was supposed to learn in the college class I'm taking. I don't know if it will work. I tell myself I don't care but I'm lying and I know it. I'll go through the motions and honestly give it my best effort. That's because it's a learning experience and I want to learn this stuff. I want to use it too. That's what this is all about isn't it? It's about knowing I can change myself and believing that I can.

Can I accept that I can't change the way things are where I work if this fails? I hope so but I'm still going to try and make a difference.

This is whut I'm sending out.


Embracing the Suck...

But only as much as is absolutely necessary.

There's an internship as part of the leadership and management class I'm taking and The Boss has graciously allowed me to do that internship here. I have a simple goal, "Make us a better Team". 

There's nothing earth shattering about any of the exercises to I have planned. They are what the sages of all things Team and Leadership say are effective. I'm simply going to direct us through a series of steps that they taught us about in class and that I've gleaned from the assigned readings. My personal assignment is to do my best to ensure that it's neither intrusive nor just an exercise in going through the motions. It needs to be real or it's pointless.

Muffin top version of the Serenity Prayer

You all know the serenity prayer in one form or another:

    God, grant me the serenity to accept the things I cannot change,

    The courage to change the things I can,

    And wisdom to know the difference.

 http://en.wikipedia.org/wiki/Serenity_Prayer  (There's some neat information here)

As far as I can tell, the first line translates directly to, "Embrace the Suck".

Sometimes The Suck is external, and a part of our daily lives that isn't going away. We work for the (PLACE WHERE I WORK) and certain things come down the pike which we have to simply embrace. At other times it's closer, like certain aspects of PITA policy. Fighting that suck is part of who we are and what we do. The continued effort towards obtaining the aptly named Purgatory network is one of the ways we meet our foe and is but one example of how we battle every day.

When The Suck is internal is where the next two lines can have more effect. Do we/I continue believing and behaving the same day after day or do we/I try and make a change? (Cliché about insanity intentionally omitted. I'll digest this stuff down to what's the most applicable to us in our place of mutual Suck.

We're in this boat together. The ride will continue. The boat will always leak and we'll keep bailing. That's the Suck we endure. Let's just make that little bit of extra effort that lets us get better at patching the holes we can, bailing more efficiently and seeing through the fog towards wherever we're going. 

The very least you'll get out of this is the personal sense of satisfaction from knowing you, and "we" because it's a team, tried.

Subject: Further education

Alternate title: Exercises in cowboy style software development

I stole this art from: http://blog.siteground.com/siteground-staging/

Sometimes we're not happy with the way things are going on around us. Lately, I've been trying to make a difference in many different things. I'm coming up with a plan of action but decided to set off on the path before the plan is finalized. I think of it as a RAD (Rapid Application Development) form of self improvement. I have a reasonably well defined goal of where I want to go and know the steps I'm taking will get me closer. So I'm off...

I think that a lot of cowboy development happens where I work. That type of behavior skips a lot of what I consider to be good practices in software development. So, I'm trying to get the other members on the team to see the value of certain practices. In this case it's writing effective unit tests. Because of the way my mind works I approach things by seeing what's wrong with it. That helps to explain the structure of the message I sent.

* It's worth noting that the developer that created this unit test is no longer with the team. Though an exceptional developer in most every other way I think he fell a bit short here. Even if he was here he wouldn't be embarrassed by this being used as an example. He was, and I believe still is, always open for an intellectual discussion.

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Subject: Further education

Below is a unit test from the OurGroup.OBP.EnrollmentPortal project. AKA: OurBigProject

Please review this unit test and indicate its shortcomings. I found at least two direct shortcomings and more than two indirect ones.

Note: This is the only unit test in the solution for ASourceii Labs.

    [TestMethod]

    public void ASourceii_GetLabs()

    {

      IOBPDataSource source = (IOPBDataSource)context.Lookup(@"DataSources\OurGroup.DataSource");

      List<LabTest> labs = source.GetLabTestsForPatient(TestPatient, DateTime.Parse("10/22/2002"), DateTime.Now, TestUser);

      foreach (LabTest lab in labs)

      {

        if (lab.LabTestName.Contains("CANCER")) throw new Exception("You dumbass");

      }

    }

Responses expected by COB today.

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

My worst fears were realized. I got nothing back. 

Utilizing some skills I recently picked up in a management focused class I'm taking I responded like this. Basically, that means I didn't admit that no one responded. I praised them for the success they might have had in hopes that some guilt might develop for their lack of participation when they believe others have.

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Subject: RE: Further education

Not bad for you simple cowboy developers.

Zone of Rant

One of, if not the most important, reasons for unit tests is to allow you to make modifications to code and be well assured that your changes did not break the code. Not only that the code fails to throw exceptions but that it still meets each and every expectation held for it. In the case of OurBigProject, like many of our applications, we can't replace the antiquated and difficult to use data layer without substantial risk. A solid suite of unit tests would significantly reduce that risk. You can pay some now or you can pay a whole bunch more later.

First things first:

- What is this test verifying? There are no comments or association to the requirement or test case specifying what is being verified. It's left up to whoever comes upon it to guess.

Other critical items:

- There are no Asserts. In MSTest the standard pattern is to use an Assert for the validation.

          All of the available Asserts: http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.unittesting.assert.aspx

- Near and dear to one of our team members's. heart is the unprofessionalism displayed in this code. I got read the riot act for using the word "poop" as a temp variable in some work I wasn't finished with and this contains the word "dumbass". This code, in this exact form, was sent to the Another Organization. Besides making us look, unprofessional the boss type people wouldn't be happy if they found out about this.

- This is the only test for Labs. It only verifies that none of the returned records contain the word "CANCER"**. If no records were returned then the test passes.

Other issues:

- **The method string.Contains is case sensitive. So the word "Cancer" would not be caught by this test.

- There is no explanation of what the input or output test data is. You don't know, without some digging, what the makeup of any of those is.

- This test throws an exception. In some testing frameworks if an exception is thrown then the system stops and none of the other tests are run. All tests in a suite should be able to be executed regardless of the pass or fail status of another test. IF you want to create a dependency between tests then do it in code using the available methods.

- The thrown exception doesn't tell you enough. (Not for some of use anyway) It should log the reason for the failure.

- There should be other tests. For example: One with a list of the expected results. By simply including a start and end date an exact list could be retrieved and compared to a benchmark.*

- It's hard to see here but this test is dependent on access to an external data source. In this case it's a test instance of a web service (That isn't working BTW) that pulls data out of a production system that we don't have full control of. One of the beauties of dependency injection is that you the developer could isolate the environment so that the external dependency is removed. Especially because it's dependency injection you could have it run both ways. Once against an environment you have total control over, making it a true "unit" test, and once against the full environment.

*Most every object in the OurBigProject project can be serialized. That means the input objects and expected benchmark values can be stored in files. That makes it easy to create and execute a wide variety of test scenarios. (I'll show how this is can be accomplished in my next installment.)

In conclusion:

Unit tests are more than a way for you to exercise your code outside of the application that will use it during development. It insures that the code does what is expected of it. The time saved by not writing an adequate set of unit tests will quickly be lost the next time anyone goes in and makes a modification. Relying on the test process at the end of the development cycle to catch mistakes you have made is failure from the onset.

 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

I don't think I'll be able to realize the effectiveness of this effort any time soon. Maybe if I open up a solution in the future and see more than one unit test per method.

Oh, and I know I need to get better at formatting my posts. I'll check into that.

Cross Tab/Pivot Queries

Been Busy:

I've been pretty busy of late with things not related to this general thread of gaining an understanding of MVC and all that it entails. One of the things I've been working on has been pulling user response data out of some survey software we're using as part of a clinical study at my real job. The project is to show the efficacy of the Text4Baby Project. The tool we used to collect the data is a modified version of Select Survey .Net (Which I highly recommend) The canned reports didn't output what we needed especially after the modifications we made.

Whut They Wanted:

It has a very relational structure in the SelectSurvey database and is a bit difficult to get data out of. One of the things the people doing the study (Real scientists) wanted was that the data be in a structure sort of like this.

RespondentId	Q1Answer	Q2Answer	Q3Answer	QNAnswer...
#1	Yes	No	Some Times	Twice
#2	Yes	Yes	Never	More than 10
#3	No	No	Never	Got Caught

It didn't look like that at all in the SelectSurvey database. It turned out to be fairly difficult to get it all worked out. For me anyway.

A bit of background:

I was riding on the shoulders of giants (Mark K. mostly) who had done a bunch of related preliminary work in figuring out the SelectSurvey database for us so it was much easier to do than if I had to do it all on my own. Additionally, many moons ago I'd come up with a way to put these column names into the SelectSurvey application using a field they already had there. It's called 'item_alias' but was intended for a different purpose. When I originally thought up the concept I had contacted the makers of SelectSurvey with my idea for a work around and suggest they add a new field to the application. A year or so later I contacted them to see how it was coming and they quoted back my hack as the suggested solution. kay-sara-sara.

The last time I wanted to do a pivot query in SQL Server it wasn't available. I'd gotten the concept from MS Access back when I was doing a lot of work with it. I couldn't understand why it wasn't available in these big database engines when little MS Access had it. Well, that was a long time ago and it could now be done in SQL Server.

Finding a Solution:

When Googling for how to do this in SQL Server. One of the first posts on the subject I found was this one: Pivot tables in SQL Server. A simple sample.: It's a pretty good example of what Pivot queries are used for and getting a handle on the general concept.

In the examples the poster was pretty much doing what I needed except I had a lot more column names than days of the week. Typing all of those into a query, and getting them right, seemed a bit daunting. What I wanted was for those column names to be dynamic and pulled out of the records themselves in that 'item_alias' field I mentioned previously.

I found how to do that in the response to this post: SQL Server PIVOT Column Data on stackoverflow.

You'll see in the response by astander that it's broken down into three parts (The first section with the CREATE TABLE is just populating a table with data so I'm not including that in this discussion)
The first part He creates a variable to store the list of columns in the right structure as indicted in the example in the first list. e.g. "[MON],[TUE],[WED],[THU],[FRI],[SAT],[SUN]" by selecting the column names using a query. (Note the COALESCE thingy) From there, he creates a string with the Pivot query in it and substitutes the results from the prior query as the list of columns to get as the results of that Pivot query.
Then it's executed.

Implementation:

About all I did was copy the text of his post and substitute in the names for the tables and columns in the SelectSurvey database.

The Details:

If you want them, please ask. It's not that easy to write up so I'm not going to put it all together and post it when my only readers at this point are one close friend and my mother. What you'd get would be queries to create the pivot data using the SelectSurvey database and some setup data. to see it work. It would take a little bit of doing because the queries I'd post would have to be modified versions of the ones I'm using that don't include the table(s) we added for our extension of SelectSurvey.

Thanks:

I'd really like to thank the poster of the answer, astande, but I don't have enough points yet on stackoverflow to post a response yet.

*I hope to someday post the entirety of the mentioned modifications we made to SelectSurvey. Actually, we didn't make any changes to the application itself. What we did was built a wrapper around it that allowed us to chain surveys. The respondent would take the first survey which would collect their unique ID. The system would then check the database and figure out which survey(s) the respondent was supposed to take next. All of this may be moot as the version of SelectSuvey.NET we have on hand is a few years old and the basic idea wouldn't work with newer versions.

Understanding Dependency Injection

Based on all the articles and postings I've found via Googling the subject it's my guess that getting a handle on what Dependency Injection can be difficult for some people. For others, not so much. So, I'm going to post some of the resources I've found and add some comments to extend what they have posted to if I feel the need.

Basic Explanations

One of the more basic descriptions I've found is this one in a blog post by Kevin William Pang titled Dependency Injection For Dummies. What I liked about it was how it used simple images to assist in developing mental pictures for the concepts. I do think it came up short in one aspect though. In the "...Why Should I Care?" section he did cover how DI can be used for testing but he didn't provide an image or tie that back to the analogy. I believe it's one of the most useful aspects of DI and worthy of a bit more in-depth explanation.

So here:

How do you test that you can use a car, the dependency in this analogy, to go to the store? You inject a mocked instance of a vehicle. You can think of it as something like a driving simulator.

Totally stolen and then modified graphic
Note the purple, virtual vehicle.

This totally removes the need for a vehicle of any kind to verify that you know how to make a trip to the store via an appropriately configured vehicle.

To add to that, you can inject a mocked instance of the store, the shopping list and the money it will cost you to make the purchase. Then, at the end of this virtual trip to the store, you can test that you came back with all the items on your list.

To stay with the analogy, to do further testing, you can inject a store that doesn't carry 2% milk and then verify that it either returns with no milk or that skim milk is substituted depending on the business logic that is expected to be implemented. You can also substitute a virtual vehicle that shouldn't work, like a riding lawn mower, and check the error response. Alternatively, inject an obscure vehicle, such as a street licensed golf cart, and ensure that it can make the trip to a neighborhood store but fails if there is a highway where the golf cart isn't allowed on the route.

In the comments section, brian goes a little way into making modifications for the classes. As my thinking is along the lines of testing scenarios I'd like to carry that a couple of steps and make it so the Car class would implement alternate modes of transportation as mentioned above and then to add an age attribute to the Person Class and then verify that the target vehicle will ensure there is a place for a child seat for passengers under a given age.

Test Framework Status Update

Just a quick note to let all my reader know what's been happening.

I've made the copy of the Test Framework project, created a new project for testing the Test Framework, put it all in a solution and done all of the anonymizing I can. I can't post the code I have yet because there are still references to the Dependency Injection framework of our internal Enterprise Library.

That means the next step is to bring in the Unity container and rip out the old one.

Wish me luck!

Background of the Test Framework WebTest

Thought I'd give a little credit where due and explain a bit of the life-cycle that the Test Framework has gone through.

The Good Ol' Days

Like a great deal of decent code, it's stolen copied from someone on the web. This holds true with the Test Framework I've been using.

I think the original code for the Test Framework came from this article Selenium browser UnitTesting from TeamCity from the blog Software Creations – Orn Kristjansson. I'm not positive but it looks good. I'm thankful for the original posters work.

When we got the library in house I used it for a little while as it was originally presented before one of the developers, Jared, got his hands on it. He tweaked it to make it more configurable with an in-house Dependency Injection Object Factory thingy**. He also got it to automatically start the the Java engine that Selenium needed at the time instead of using the .BAT file I had been using.

That post mentioned above was from July of 2010. Back then, Selenium worked much differently than it does when I'm posting this. Things changed a lot with the release of 2.0, the WebDriver version. I'm happy with the changes that were made if you don't mind me saying so.

After Selenium 2.0 came out, I went into the Test Framework library and butchered modified it to work with the WebDriver version of Selenium. Part of which was taking out the starting of the Java engine (Which had broken by then) and that external dependency. I also messed up how things worked.

With that experience with the library my confidence in coding grew and I made some modifications to make pointing at different environments that needed to be tested easier to do. Now, only a minor change in one place can change that environment under test as well as the behavior of the test suite. That's to include using different test data against the site under test. Those changes worked but it was a convoluted implementation. Only when I went in to start this rework did I actually see what I had done and then correct it.

What's Changing

As I think I've mentioned before, we're planning on upgrading our in house version of an enterprise library. It includes much of an early release of the MS Enterprise Library plus some internally developed utilities along with an external Dependency Injection/Object Factory thingy**. I've made the command decision to switch over to a newer version of the MS Enterprise Library without the 'porting' to our namespace. That also includes replacing that in-house Dependency Injection Object Factory thingy with Unity.

** "Thingy" That's a very highly respected technical term. You should learn it and use it often.