Month: June 2019

Posted on

Google Maps Routes Cars Into Mud…

Quite a few news outlets are reporting a mistake in Google Maps that led to cars being stuck on a muddy road.

Apparently, the highway to Denver International Airport was backed up so Google Maps suggested a detour route – unfortunately this detour route was a dirt road that became mud after earlier rainstorms. A number of cars were stuck in the deep mud and had to be pulled out. See the video at this CNN article:
https://www.cnn.com/2019/06/26/us/google-maps-detour-colorado-trnd/index.html .

This Time article is a nice summary:
https://time.com/5615813/google-maps-mud-detour/ .

Screenshot of Time article, linked above.

It’s fun to blame Maps for incidents such as this, but it underlines how important it is to review maps and confirm where the route takes you. It would have been easy to pop open Google Maps Satellite View and quickly thumb through the overhead view to see where the detour took you – if you see a poorly maintained road, or any other warning signs, it’s definitely a good idea to avoid.

Posted on

Gmail API Lockdown

I wanted to highlight this ArsTechnica article, Gmail’s API lockdown will kill some third-party app access, starting July 15, for several reasons.

The Security Audit Rule

Last October, Google announced that all applications accessing and storing Gmail data must pass a security audit from an outside firm – Google estimated that such an audit would cost $15,000 – $75,000 or more. Many useful Gmail plugins and integrations are shutting down due to this requirement, even open source applications where the code is available for all to review.

Historically, Google has been slowly repositioning Gmail from an email inbox to an app platform itself: there are Chrome addons and Gmail plugins to turn Gmail into a CRM, a todo list, a kanban board, and so many other integrations – which is why I’m surprised to see Google seemingly reduce the usefulness of Gmail by adding these requirements and losing these plugins.

We’ll see how this goes, but I would bet on Google slowly loosening up restrictions over time, or possibly offering subsidies for the security audits of popular Gmail plugins.

Google Reader Strikes Again

A particularly cheeky ArsTechnica commenter wrote the following insightful comment:

ArsTechnica commenter criticizes Google for shutting down other Gmail integrations.

And quite a lot of commenters seem to agree:

An ArsTechnica commenter agrees with the previous poster, criticizing Google for shutting down Gmail integrations.

Posted on

WordPress Twenty Seventeen Theme Page Spacing

I think the WordPress Twenty Seventeen theme is pretty close to the ideal starter WP template – it’s simple yet looks very nice, especially if there’s a nice header image.

One of the major annoyances with using the theme is that there’s so much empty space in a default page. For example, here’s how my /about page looked like with just the default CSS (note how small the “ABOUT” text is, and it’s a H1 heading!):

Picture of unstyled

I added the following custom CSS to help reduce the space and slightly increase the size of the H1 text:

h1.entry-title {
	font-size: large !important;
	font-weight: bolder !important;
}

header.entry-header {
	padding: 0 !important;
	margin: 0 !important;
}

div#content.site-content {
	padding-top: 1em !important;
}
Posted on

Firestore Errors

Most of my apps are using Google’s Datastore, but I decided to try out the new Firestore on a test application. I’m receiving quite a few of the below errors:

io.grpc.internal.ManagedChannelOrphanWrapper$ManagedChannelReference cleanQueue: *~*~*~ Channel ManagedChannelImpl{logId=346, target=firestore.googleapis.com:443} was not shutdown properly!!! ~*~*~* (ManagedChannelOrphanWrapper.java:151)
    Make sure to call shutdown()/shutdownNow() and wait until awaitTermination() returns true.
java.lang.RuntimeException: ManagedChannel allocation site
	at io.grpc.internal.ManagedChannelOrphanWrapper$ManagedChannelReference.<init>(ManagedChannelOrphanWrapper.java:94)
	at io.grpc.internal.ManagedChannelOrphanWrapper.<init>(ManagedChannelOrphanWrapper.java:52)
	at io.grpc.internal.ManagedChannelOrphanWrapper.<init>(ManagedChannelOrphanWrapper.java:43)
	at io.grpc.internal.AbstractManagedChannelImplBuilder.build(AbstractManagedChannelImplBuilder.java:514)
	at com.google.api.gax.grpc.InstantiatingGrpcChannelProvider.createSingleChannel(InstantiatingGrpcChannelProvider.java:223)
	at com.google.api.gax.grpc.InstantiatingGrpcChannelProvider.createChannel(InstantiatingGrpcChannelProvider.java:164)
	at com.google.api.gax.grpc.InstantiatingGrpcChannelProvider.getTransportChannel(InstantiatingGrpcChannelProvider.java:156)
	at com.google.api.gax.rpc.ClientContext.create(ClientContext.java:157)
	at com.google.api.gax.rpc.ClientContext.create(ClientContext.java:122)
	at com.google.cloud.firestore.spi.v1.GrpcFirestoreRpc.<init>(GrpcFirestoreRpc.java:122)
	at com.google.cloud.firestore.FirestoreOptions$DefaultFirestoreRpcFactory.create(FirestoreOptions.java:80)
	at com.google.cloud.firestore.FirestoreOptions$DefaultFirestoreRpcFactory.create(FirestoreOptions.java:72)
	at com.google.cloud.ServiceOptions.getRpc(ServiceOptions.java:510)
	at com.google.cloud.firestore.FirestoreOptions.getFirestoreRpc(FirestoreOptions.java:315)
	at com.google.cloud.firestore.FirestoreImpl.<init>(FirestoreImpl.java:77)
	at com.google.cloud.firestore.FirestoreOptions$DefaultFirestoreFactory.create(FirestoreOptions.java:63)
	at com.google.cloud.firestore.FirestoreOptions$DefaultFirestoreFactory.create(FirestoreOptions.java:56)
	at com.google.cloud.ServiceOptions.getService(ServiceOptions.java:498)
Screenshot of Firestore exception - failure to shut down in code.

These errors stopped when I called close() on the com.google.cloud.firestore.Firestore object after I was done with storage operations:

Javadoc for close() on com.google.cloud.firestore.Firestore.

I can’t help but feel a little disappointed at this new requirement to close the Firestore connection. It feels like a regression from the Datastore – there was no need to close the datastore object after usage.

Posted on

WordPress Annoyances

I haven’t been posting as much as I want to lately – I’ve been fiddling with some WordPress issues and a lot of work from my day job.

Here’s some minor thoughts that don’t deserve a post by themselves:

Routing

{
  "code":"rest_no_route",
  "message":"No route was found matching the URL and request method",
  "data": {"status":404}
}

I wrote a custom WP plugin which accepts requests from an App Engine application and returns some custom data. Unfortunately, my app on GAE was returning the above error whenever it tried to make a HTTP request to the WordPress app.

Long story short, the register_rest_route() on my plugin only declared a GET endpoint, and my GAE application was trying to use POST. Make sure you’re using the same HTTP type if you get this error.

WPEngine Firewalls

By default, WPEngine has a firewall that blocks GAE-originated requests from hitting WP plugins – fortunately, if you need GAE to WPEngine-hosted WP communications, you can email WPEngine through their contact form to remove the firewall on a per-blog basis.