Pardner's Roundup

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.

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.

How did Gutenberg become the new default for editing WordPress blogs?

When you click in para 3, the ‘helpful’ popup obscures para 2.

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.)

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