Pardner's Roundup

Once Heroku support showed us how to specify the Postgres version for in-dyno Postgres in our app.json we re-ran our Rspec rspecs and were pleasantly surprised how fast they ran. (Specifying Postgres 9.6 seems to be required for Rspec for a Rails 4.2.11 app; using the default Postgres 10 causes errors related to the change of the increment_by field in P 10)

The “trick” to specifying the Postgres version for in-dyno Postgres is to use an environment variable. If this is documented anywhere we could not find it, so perhaps this will be helpful to someone else:

While we did not expect to see any difference, we did confirm that our 10 minute deploys to a Heroku staging server typically take the same amount of time whether we use the old git push vs Github integration.

We did not test whether a deploy with significant new data (a ton of new images added to the repo for example) was materially faster from Github.

UPDATE: using in-dyno postgres puts Heroku CI on par with running Rspec locally!

Experimenting with using Heroku CI for a Rails app, we were a little surprised just how slow Rspec specs run.

As you can see however the runtime cost is about the same since the largest dyno performance-l costs twice as much as the default dyno used by Heroku CI.

Unfortunately, we cannot test using in-dyno Postgres since Heroku does not seem to offer a way to specify the Postgres version for in-dyno instances.

Next Step: If we can get parallel tests to run, it will be interesting to see if the overall runtime (and cost) remains constant so we can shorten the test to say 2 minutes by running 16 dynos.

If so that may be GREAT news for using Heroku CI vs Travis CI or Circle CI, whose fixed monthly cost is HUGE for even a few concurrent instances.

An issue we ran into recently is: if the same development machine is running two Vagrant instances, how can an app running onfoofetch data from a url onbar.

The two-part ‘trick’ if foo wants to fetch data from bar, is:

1) each app’s Vagrant file needs a line:

config.vm.network :private_network, ip: PVT_NETWORK

where PVT_NETWORK is a local IP, is different for each Vagrant file, and probably needs to be in the same subnet. For example PVT_NETWORK might be 192.168.50.50 (foo) and 192.168.50.51 (bar)

2) foo accesses bar via the PVT_NETWORK IP address not the “real” IP you would use with a web browser.

In our Rails example, we have each app running on a different port, so foo is on localhost:3000 and bar is on localhost:3001, so foo would access a url on bar via

http://192.168.50.51:3001/some_url

I despise irresponsible mass-emailers like JibJab.

A truly unfortunate real estate team in California was horrified yesterday to find that JibJab (jibjab.com) pissed off legions of their customers as a direct result of JibJab’s inept and irresponsible practices (which are also, in my non-legal-expert opinion, illegal under CAN-SPAM).

The agents’ intent was simply to blast out a holiday card to their email list via JibJab. It became, in their words in the apology they then had to email to their entire email list, a “debacle” and “nightmare”.

By irresponsible (and possibly illegal), I refer to the fact that when JibJab sent an email on behalf of the agents, they did not provide any opt-out link. In my opinion, that seems to be a fine-worthy CAN-SPAM violation because these were not transactional emails.

By inept, I refer to the fact JibJab blasted many duplicate emails to the same recipients, which in the words of the agents made “tons of people angry at us.” (Even if we allow the possibility – although I have no reason to believe this is the case- that the agents somehow submitted duplicate requests to send the same ecard to their list, JibJab is still in my opinion woefully incompetent for allowing the same card to be sent to the same recipient from the same account multiple times.)

As an example of JibJab’s ineptness, here is a copy of our inbox for one day:

Naturally, JibJab does not answer their support phone (the greeting tells you to email them), and they (thus far) have ignored both email we sent alerting them of the dual issues of repeat sending and no opt-out mechanism. (I tried contacting JibJab within minutes of the first duplicate, so they could have saved countless pissed off recipients had they offered real-time support option.)

Ironically, JibJab’s most recent tweet boasts their product “keeps on giving” but I think we can all agree that blasting 29 duplicates isn’t something to boast about.

I can only wonder how many hard-earned customers and prospects JibJab customers have lost due to JibJab’s ineptness and irresponsibility.

Short version: the $200/month additional premium for a Silver plan (vs Bronze) almost never gets recouped through the lower copays. (Remember, although you hit your lower Silver deductible sooner, you still pay 20% of all costs until you hit the out of pocket maximum, which on the Silver does not happen until your expenses hit something like $12,500. But on Bronze, once you hit $4000 in expenses your coverage in 100%. The extra premium for Silver, combined with paying out of pocket until you hit $12,500, is the one-two Silver sucker punch.)

Long version: For those of you deciding which ‘color’ version of healthcare plan to choose, there is a very high possibility that the Bronze is less expensive. This guy does a detailed analysis which, despite being a few years old, definitely applies in my case. http://ideas.4brad.com/surprising-math-obamacare-levels-go-…

I did my own spreadsheet for our employer BlueCross plans and found that by the time you factor in premium costs, Bronze was less expensive for anything other than the case where covered medical expenses fell into the narrow range of 4000-6000 for the year (and even then, in that narrow range where Silver was less expensive, Bronze only cost a couple hundred dollars more than Silver).

The top chart is the usual case where only ONE subscriber incurs the medical expense on the X axis (and the other subscriber is generally healthy), the bottom chart is if BOTH subscribers use the same level of medical expense.

Caveat: If your “member cost” (the insurance allowed amount) for prescriptions is significantly higher than your Silver co-pay, that difference in effect “adds” to your premium cost for Bronze. For example suppose you are on Silver or Gold right now and every month you take XYZ, and on your insurance claim each month you see the Provider (retail) cost for XYZ is $600, the insurance allowed cost $320, member pays $20. Your copay benefit in this case is saving you $300/month vs the normal insurance-allowed rate for that drug.

Suppose you want to sell an item online, and post photos and videos of the item online. And to protect yourself you plan to meet a potential buyer at a public place such as a Big Box Store parking lot. That’s more or less pointless if you link your ad to your photos and videos but they were taken at home, if they are geotagged, since you’ve now shared your home address with anyone on the internet. And geotagging is on by default for many people.

For Mac users, with photos, it is relatively simple to remove the geotag data right within Preview. (Open the photo, under Tools show Inspector, click on the ‘i’ icon, click on GPS, then click ‘remove location information’.)

However, for videos, the Mac offers no such shortcut to remove the location information on a video you took… a lamentable oversight IMO.

The free FFMPEG command line app will do the trick, and is easy to install.

Assuming you have Homebrew installed (Google it, if not):

brew install ffmpeg

Once installed, run it for each video with the options
-map 0 -map_metadata -1 -c copy

I copy the videos into a desktop folder such as ‘nogps’ then run ffmpeg for each video in that folder:

cd ~/Desktop/nogps

ffmpeg -i IMG_1000.mov -map 0 -map_metadata -1 -c copy NOGPS_IMG_1000.mov

ffmpeg -i IMG_1001.mov -map 0 -map_metadata -1 -c copy NOGPS_IMG_1001.mov