From their press release, the following Chevy models will have Android Auto and Apple CarPlay support:
For those unfamiliar with Android Auto or Apple CarPlay, it lets you replace or supplement the infotainment system that comes with your car. For example, you could use a music or navigation app running on your phone, rather than using the software that came with the car. This will be especially interesting 10 years from now (2025!), when you might really wish you had a more up-to-date infotainment system in your 2016 model-year car. These Android and Apple systems make it much easier to update how your car works, especially compared to physically removing part of your dashboard and replacing it. Personally, I’ve been thinking it would be interesting just to leave an old smartphone in the car, charging over USB and loaded with music and maps that were downloaded over WiFi.
I’m especially intrigued by this because I’ve been considering a replacement for our 2003 model-year car, and it’s important to think 10 years ahead for such a big purchase. (After all, we’re using a 2003 model-year car in 2015.) While Android Auto or Apple CarPlay support isn’t likely to make or break our decision, it definitely has its benefits.
The way Microsoft presented the Android and iOS support on stage last week wasn’t particularly encouraging. The way that Projects Astoria and Islandwood—the codenames for Android and iOS app support, respectively—were promoted in the keynote presentation, one might think that the Android and iOS support were pretty solid substitutes for the Universal Windows Apps that are native to Windows 10 on all the hardware form factors it will support. It seemed like porting apps from those platforms would be an effective alternative to any plans to develop native Windows applications.
This is pretty crazy: Windows will support Android and iOS applications through compatibility layers. I don’t really see the iOS layer getting a lot of traction just because it takes a lot of work, but the strong Android support is going to further entrench Android as a platform you can deploy to almost anything (second only to HTML5).
Can’t push commits to GitHub, but need to move them to another clone? Adding another remote is a good option to get you out of a bind.
Why did this come up?
We do a lot of pair programming at Continuity. One of the great things about it is that if someone is out sick, you can usually depend on the other person to know the details of what was happening. But what if both people are out sick and they forgot to push their branch to GitHub and the deadline is today?
(That happened last week!)
The solution described in this post is a little specific to how we pair program remotely. Our team is almost 50% remote developers, and we all share access to the same EC2 instance. We use wemux and vim to pair (among other tools), and the provisioning is automated by puppet.
Back to the tale of the missing pair, one idea that came up was installing another SSH key to the missing person’s ~/.ssh/authorized_keys, but that has a number of problems:
That makes their account a shared account. Because you can’t tell who was using it, if someone did something bad using the account, you can’t easily tell who did it.
If the key is added by puppet (as it should be), that adds a lot of labor just to add a temporary key.
You still can’t push any commits to GitHub without also installing the key there.
Finally, installing keys on another user’s account just feels like a practice to avoid, if no other reason.
Instead, what we decided to do was to become their user via sudo (which is logged) and then push to a local clone of the git repository. That might sound complicated if you’ve only ever used git in combination with GitHub, but it’s actually a lot simpler than you’d think.
What we’re going to do is push the absent user’s code to a shared directory, then pull it to your clone of the repository.
We’ll refer to the absent user as them and the user that needs access to the code as you.
Just to set the stage, let’s look at the normal remotes for a clone from GitHub:
That’s a lot like a private GitHub repo, but without any of the pretty web user interface or authorization management.
I hope this example helps illustrate that git is very flexible and can bend to your needs. If you’ve only ever used GitHub as a remote when using git, you’re missing out on some useful functionality! However, it’s it’s still best to have all your code in a central location, even though you could add a thousand remotes. Like any tool, know when to use it!