OWC: “own it” when you ship a broken item

I have two OWC thunderbolt external drive units sitting next to my Mac. But they will never be joined by any more OWC products.

I believe that when  company ships a defective product that they are nuts not to bend over backwards to “right” the problem, immediately, and without asking their customer to “loan” them more money while the replacement and return are being sorted.

I ordered an OWC Aura Pro X upgrade SSD kit for a Macbook Pro late 2013. It arrive on time, but an incidental item was damaged upon receipt (an external case that lets the original SSD be used as an extra external drive had a LED broken off and rattling loose inside the case).

Took photos. Called OWC. Offered to send them the photos. Within 10 minutes of the item begin delivered.

OWC was “very sorry” but flatly refused to put a replacement case in the mail until either I returned the bad one, or prepayed for the replacement to get a credit later. They said they could not ship a case “for free”.

Free?  They had my money. I had a broken case. There’s nothing “free” about that.

So at that moment in time OWC did have 100% of their money, but I did not have 100% of what I paid for.

So the notion that it was my problem to eliminate their perceived risk that I might fail to return a case that costs them maybe $20 to make one seems ridiculously short-sighted.

But so be it. Entire $400 order was returned with an RMA the same day for what I expect to be a full refund.

Macbook Pro 2013/Sierra as fast as Macbook Pro 2018/Mohave for Rspec/Docker/Rails Dev

TLDR; An old 2013 2.3GHz quad core Macbook Pro 15″ w/ 16GB running Sierra (10.12) is as fast as a 2018 2.6GHz 6 core Macbook Pro 15″ w/32 GB under Mohave (10.14). A Mac Mini 2018 (32gb) running Mohave is 21% faster than both.

My trusty 2013 15″ MBP has been a reliable workhorse for a  range of development tasks, but as we have moved to using Docker in our dev environment, but with only 4 cores, 16GB, and a 500GB SSD,  I considered both the 2018 Mac Mini and an Apple-refurbished 2018 MBP, both with 32GB RAM, faster processors, and 1TB internal SSD.

Admittedly, I had visions harkening back to 1984 when, as a grad student/developer, I hocked the farm to get one of the first IBM “AT” computers to hit Palo Alto, and watched the compile times for my educational app plummet from 20 minutes to about 4 minutes.

I even convinced myself I could tolerate the MBP touchbar / trackpad / keyboard since the vast majority of the time I’m at a desk using an external keyboard and trackpad.

But I was disapppointed how modest the performance gains (if any) were.

Unfortunately, the new Mac hardware under the new Mac OS is not a compelling value proposition.

When the 2013 MBP is running Sierra, and the 2018 Macs are running Mohave:
Mini2018: 5:02,  MBP2018: 6:07, MBP2013: 6:13

When the older 2013 Macbook is upgraded to Mohave, the 2018MBP is 17% faster than the 2013 MBP. (But no escape key.)

So apples-to-apples-to-apples under Mohave, the Rspec runtimes are:
Mini2018: 5:02,  MBP2018: 6:07, MBP2013: 7:20

Test setup: A suite of about 800 RSpec examples running in Docker Desktop v 2.0.0.3 for Mac… a web container with a Heroku-16 stack for a Rails 4.2.10 app with ruby 2.4.5, and a database container with Postgres 10.5. Tests were run 3 times on each platform and the times averaged. (Docker preferences set to 2 cores, 4GB RAM, 1 GB swap)

Verdict: the Mac Mini and the 2018 MBP both go back to the Apple Store tomorrow within Apple’s generous 14 day return window.

Fortunately, while I do need an 1TB internal SSD drive for the 2013 MBP, Apple did not completely future-proof the 2013 MBP and the internal SSD can be replaced.

Just don’t even think about buying a Fitbit Versa

Or at least, buy it from Costco, and try to remove / replace the band before leaving the parking lot, so you don’t have to make an extra trip to return it… because you WILL return it.

Google “fitbit versa band problems”.

Seriously, worst wristwatch band in history. Tiny little bend/breakable pins and a bizarrely difficult ‘push down to release band’ pin that can’t be reached because the band is in the way.

(Oh yeah, still no calendar… “so-Called-Smart” watch with no calendar. Still does not allow you to change the volume on some devices like Apple AirPods when listening to music.)

HemmorrAndroids even more painful than IOS

Daughter called from a borrowed phone because her Samsung Galaxy S9 bricked itself during a routine update. So she gets to drive an hour to the nearest place that can re-flash her Android ROM.

Yes, apparently that shit still happens in Android-land.

Now don’t get me wrong, I despise IOS since IOS 9. And Apple’s jack-booted-thugs killing the ability to install older versions of IOS that actually worked. Especially because Apple software quality has gone right into the shitter.

But I guess Apple can get away with it as long as Google/Android continues to suck so bad.

Making Heroku CI (almost) as fast as running Rspec locally

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)

 Mac OS XHeroku CI "M" dynoHeroku CI "M" dyno
IN-DYNO postgres
Heroku CI "L" dynoHeroku CI "L" dyno
IN-DYNO postgres
Dyno cost/hour$0.34$0.34$0.68$0.68
Run Time5:5359:0013:27 !!!31:438:03 !!!
Heroku cost$ 0.34$ 0.08$0.36$0.09

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:

In order to change the Postgres version for the in-dyno add-on you’ll need to create a new environment variable in your app.json like this:
  “environments”: {
    “test”: {
      “addons”: [“heroku-postgresql:in-dyno”],
      “env”: {
        “POSTGRESQL_VERSION”: {
          “value”: “9.6”
        }
      }
    }
  }
}

 

 

Heroku Deploys via Github are not faster than using git push

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.

Heroku CI is remarkably slow, but half as slow if you use the largest dyno type

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.

 Mac OS XHeroku CI "M" dynoHeroku CI "L" dyno
Dyno cost/hour$0.34$0.68
Run Time5:5359:0031:43
Heroku cost$ 0.34$0.36

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.

4 Most Remarkable Shortcomings of Apple Watch Series 4 (e.g., why I returned it)

That’s a lie. It’s NOT an AirPlay source:
See https://support.apple.com/en-us/HT208728

Ooops. Even on version 5 of Watch OS,
Apple forgot to ‘mirror’ your iPhone’s

default alert setting to your Watch, or provide
any other way to add an alert to an appointment.

For someone who uses Macs and iPads and iPhones, there’s a lot to like about the Series 4 Apple Watch (GPS + Cellular, watch OS 5.1.2).

But I returned mine to the Apple Store after only 3 days because:

  • The Deal Killer: Cannot create appointments with “alerts” – if you use the Watch to create a Calendar appointment, there is no way for the Watch to add an alert, such as an alert 30 minutes beforehand. So your appointments created with a Watch behave differently than the ones you created with your iPhone. (If you create an appointment via an iPhone, or an iPad, or a Mac you can set a default alert, but not with the Watch.) This was confirmed today by Apple Support who escalated the issue to engineering.
  • Calendar displays only current month. Of the many bone-headed things Apple has done in the post-Jobs era, a Calendar app that will not display months other than the current month deserves special mention. If you display the month-at-a-glance calendar, and turn the scroll knob, or swipe, the Watch displays… the same (current) month.
  • No 5 GHz Wifi support  – had to dumb-down my home wifi network to 2.4GHz for the Watch to connect correctly to the iPhone, even though it said it was connected it wasn’t connected to the iPhone via Wifi. Apple documentation is silent about the need to dumb-down your Wifi to 2.4GHz… One symptom is ridiculously slow music syncing when adding playlists to your watch if your iPhone connected via 5GHz and your watch connects via 2.4GHz… but the iPhone offers NO way to “see” what Wifi speed your iPhone is connected, so good luck debugging this.
  • No Airplay support – despite offering an “Airplay” option right on the Control Center when selecting audio output, the Watch is NOT on Apple’s list of Airplay audio sources. Confirmed with Apple Support on lengthy call: if you have a nice stereo connected to an Apple TV, no, you cannot stream audio to the Apple TV’s sound system. So the “Airplay” option on the Watch is a lie… iPhone and iPad and Mac Airplay options DO connect to my Apple TV (audio and/or video) the Apple Watch will not show an AppleTV among the audio destination options. (I thought perhaps it was because mine was a 3rd Gen AppleTV but Apple Support said no version of AppleTV can play music from a Watch.)
  • BONUS Shortcoming: No Phone or Messages quick-launch option for the new Infographic faces. Oddly, the fancy new faces do not support the two most important options (which they call complications)… no phone and no messages.

 

How to allow two Vagrant apps to talk to each other

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