slaying the giant

If you’re like me—a coder—then you’re pretty particular about which browser you use everyday and any attempts to coerce you into using a different one amounts to an annoyance.

Probably the highest on my list of try-our-browser annoyances is that dished up by Google on a daily basis.


Google Support indicates that it will stop displaying this ad if you click the small x in the corner but I have not found this to be the case. It continues to display over and over again.

And yet, I think I’ve managed to defeat Google’s advertisement pane and provide the solution here. I describe the technique for Internet Explorer but a similar fix is likely available for other browsers, too.

  1. Create a text file, say, in your Documents folder with a name like MY-IE-Default-Style.css
  2. Add the content indicated below to that file
  3. In Internet Explorer -> Tools -> Internet Options -> General tab -> Accessibility -> User style sheet (check the box) and Browse to find the stylesheet you just created
  4. Exit out of all Internet Explorer windows
  5. Start Internet Explorer and go to, noting that the nagging panel on the right should be gone

.gb_ga {
     display: none;


Looks like Microsoft has updated their own style so it will be necessary to update our own to compensate.

.gb_ha {
display: none;
#gbsfw {
display: none;

This technique should work to hide offending DIV tags on multiple sites but you’d need to be comfortable reviewing HTML source and using Internet Explorer’s F12 functionality to inspect the offending element. Target the DIV tag that you want to hide and set its CSS style’s DISPLAY attribute to NONE as I’ve done. It helps if you understand CSS coding but this is the basic way to do it—just add more paragraphs of style data to your User style sheet and you should be set.

Adobe PhoneGap


In 2011, Adobe purchased an existing mobile application development framework by Nitobi, branding it at that time with the name PhoneGap.  They’ve since released it into the open source arena as “Apache Cordova” although many of us still refer to it as PhoneGap.  If you’ve ever attempted to create native iOS, Android or Microsoft Phone applications then you’ll enjoy this new multi-platform approach.

Before PhoneGap, you’d have to install a development kit for each of the various platforms you wanted to target.  And then, you’d need to learn the platform language of each major player:  Objective-C or Swift for iOS, Java for Android and XAML with C# for the Microsoft Phone.  Good luck trying to then design and maintain three completely-different collections of phone app code which hope to provide the same functionality.


But now with PhoneGap, you use what you probably already know:  HTML, JavaScript and CSS.  You then either 1) compress your collection of files using a ZIP file and upload this to Adobe’s website or 2) use the popular repository to manage your software changes and then tell Adobe the location of your github.

I’ll add to this that jQuery Mobile does a great job of streamlining some of the work you can do with PhoneGap.  It includes both methods for interacting with the browser’s DOM and a nice collection of CSS for displaying and lining up the widgets your app will need, for example, phone-styled push buttons that are sized correctly for fingers.


An initial set of app code is created from a command-line interface, producing a collection of files you’ll need for your app.  You’ll usually focus on two files within this collection:  config.xml and www/index.html.  The first will configure the name, version and rights that your app will need and the second defines the interface.  Use any editor you’re comfortable with.  And if you’re familiar with the github source code management then this can be useful later when you build your app.

You usually develop with the help of the PhoneGap Desktop App plus a phone-specific version of the PhoneGap Developer App.  The Desktop App reads your code and serves up a development version of your application; the specific Developer App for your phone will allow you to test your code.  As you make changes in your code the Desktop App will send the new version to your phone so that you can instantly see the change.

Up to this point, none of this yet requires any build keys from Apple, Microsoft or in the case of an Android app, your own self-signed certificate.  Since PhoneGap’s Developer App itself is signed, you’re good to go.


The default set of files from PhoneGap comes pre-equipped with the Jasmine test suite built in.  Edit the www/spec/index.js file to modify the default tests, verify that the PhoneGap Desktop App is running and then execute them by bringing up the /spec folder for your application within the PhoneGap Developer App.


When you’re ready to start seeing your application as a stand-alone app you can then build it on the PhoneGap Build website.

You have two choices for pushing your code to PhoneGap Build:  1) compress your files into a ZIP file and upload it or 2) use a repository for your project and tell Adobe that location.

Since phone apps need to be digitally-signed to identify the developer it’s then necessary to upload to PhoneGap Build one or more keys for this purpose.  An iOS app will need an Apple Developer key, a Microsoft Phone app will need a Microsoft Developer key and finally, an Android app uses a self-signed certificate that you can create without Google’s knowledge/consent or paying them a fee (as is the case for the first two platforms).  The PhoneGap Build website provides enough guidance in this area.

Once built, the PhoneGap Build website provides one or more individual binary downloads on a per-platform basis as well as a QR Code scan image that you can use to direct your phone to fetch the appropriate one.