Mikester's Blog

Degradation of the web

The motivation to earn money is a powerful one indeed.  Money is like oxygen in that you need it to survive.  So just like a creature that is gasping for air, some will do anything to get another breath of money, sometimes desperately and often without regard to the consequences.   There are many ways to earn money but they ultimately fall into two categories:  ones that contribute to society and ones that don't.  In this society, it is very difficult to do something that has no effect.  If one is not contributing to society, it is safe guess that one is parasitic to it.

I encountered this second condition recently when I tried to legitimately get a domain name for a small business.  The domain I was interested in had expired and was set to be released to the public.  I back-ordered the domain through godaddy; unfortunately, someone else did the same and they were the ones that got it.   Anyway, the domain was owned by a jewelry store and it operated a site for some time.  I don't know what happened, only that it was no longer operating and the opportunity to get this domain appeared.  So I signed up for godaddy's backorder service and while I think godaddy is a fine organization, don't use them to snag expiring domains.  It is not their specialty and they essentially get money up front with no guarantee of success and they don't try hard enough.  Of course if they are unsuccessful, you can use the credit for another domain until they are successful in getting one.

If the person or organization that scored the domain name actually was a  jewelry store selling jewelry on line, it would at least have gone to a good use.  But I have discovered that the other party is using it solely for content ads.  What are these ads?  Well they are the graffiti of the web.  These are sites that only have clickable links that take you to other parts of the web, and in the process do three things:

1. Earn money for the site holder when an ad is clicked
2. Drain the ad budget of the advertiser
3. Earn revenue for Google (or any of the other content providers)

Of course there are other latent effects.  Consider this one:  rob a legitimate business of a good domain name for their business.  Here's another one: make the web less pleasant for the billion people using it by having to come across web graffiti.  I wonder how many man hours, globally, are used up in the process.  Yea, it's only a second or two and then you get out of the site.  But multiply that by the billions and you are talking about some serious time that has been taken out of people's lives.

You've all seen these content sites - the graffiti of the web.  You find these sites, replete with content ads and little or no content, that are there for the sole purpose of generating money for the site holder and to drain the advertising dollars from the advertiser, who generally has little knowledge of how this works.  It is sickening.  I saw my google advertising costs quadruple with no return.  I turned of the adsense (content) ads, and lo and behold, by google charges dropped by 75% and yet my income was unaffected.  So the net result:  I was paying google a lot of money for nothing.

I have another client that has a colleague that has purchased, according to him, some $300,000 in domain names for this very purpose.   The problem with this practice is it delivers no value to the marketplace.  Very few of these clicks are legitimate, in my estimation, or at least from my own experience.  With this business model, click fraud is rampant.  One can out source to click farm outfits where ads are clicked all day long. 

Google is in a precarious position.  The more fraud, the more revenue the earn.  The more fraud, the worse their reputation becomes.  Its reputation has already suffered yet google says to the advertiser you should just let it happen.  My own take on it is this is just pure googlese.

My solution is educate fellow business people that have PPC ads that you may be enriching google by allowing this practice.  The more this becomes common knowledge, and it will take some time, the less you'll see of these worthless ads and graffiti pollution will decrease.   So for educational purposes, read here about what advertisers are saying.  And a great article on this phenomenon is entitled Something Rotten in Adsense.

We've seen changes in the web.  Remember pop-up ads?  They are almost a thing of the past.  Let's educate our fellow advertisters and bury content ads once and for all.

 

Pay now, save later...

There are so many approaches to developing software and each has its adherents that feel like their way is the only way.  I am of the opinion that there is always a correct way to do anything and we sort of label that it in our industry as a best practice.  Best implies it is superior to all other alternative approaches.  I doubt there are two ways of doing anything that are different in procedure and equivalent in getting the result.  If one were to bake cookies, there are undoubtedly a multitude of permuations on how to do this.  Some may result in equivalent cookies in terms of quality but they will likely be different in some other aspect, like the time it takes from beginning to end, or the cleanup time required.  So sometimes it is not obvious which is the best approach if the end result is the same. It takes measurement to determine that and few people have the stomach.   But as programmers, we have all been guilty of shortcuts, like hardcoding data in a source file that really should come from a data file or configuration file.  Often these practices filter in during crunch time.  We do it to get a project done, but we probably haven't thought about the other factors, like reusability or maintainability.  Both of these come into play later on.  If you are not reusing code very much, then you are probably sloppy in design or implementation or both.  At least that's my take.

I have had a lot of major realizations recently about doing things the right way.  For example, I just finished a module that is highly resuable and I will probably make use of it in many applications to come.  It took me about 2-3 days to complete and I doubted myself throughout the development.  I wondered if this was really worth the extra effort.  But I made a decision early on to push through the development of this module, regardless.  I could have stopped at several points with the idea that it's good enough.   That has been my operating basis for a long time.  It's probably in some respects due to my engineering background.   Engineering doesn't always seek the best solution but the one that makes a lot of sense considering a multitude of other factors.

So what module did I develop?  Well I've been wanting some binary files that could be created from a build script.  The binary files are created from a CSV data file and an XML schema file.  I created a console program that takes these input files as arguments and creates an output file in a binary format that is compatible with a Delphi memory table component that I use.  So binary files created in this way can be read by an application at startup (or first demand) and are held in memory for blazing performance.   The other approach was to add fields manually to the component through a dialog box interface that is a bit clunky.  It works, but it also means I have to do this for every memory table in every application from now on.  It means populating the data in a grid and then saving it to a binary file.  That means I needed a helper application to enter data.  Sure it's an easy application to write, requiring a grid, a memory table, a data source, and a database navigation bar.  This helper application is also not very friendly to reuse because each application may have a different schema, which means editing the memory table fields and so on.

With my new module, I am now able to keep in source control the XML and CSV files and let my build script generate the binary files, much like a compiler generates binary executables.  The nice thing about this is I now have a mechanism of great reuse.  I can simply create a CSV file (in Excel no less), and document my schema (also very easy) and then put the result in a FinalBuilder build script and I'm done with input data.  In my application, I have a helper class that enables me in one line of code to load that binary file and it's in memory for my application to use.

Well I did spend some time doing this, but I also documented my process and I will be using it in a lot of applications from now on.  It is a pay now, save later proposition.  I believe it is essential to create some future savings in one's development situation. Time invested now will be saved later, and saved later with interest.  Of course you have to evaluate whether you will ever get the time back.  It may not make sense in every circumstance.  You have to use common sense and work out whether it is a correct decision for your immediate scenario.  I give the benefit of any doubt to building it the right way.  There is a high likelihood that you will find ways to reuse it and your estimates of reuse could be on the low side.