An update to an older post about using the iOS Simulator from the command line.
The Simulator ships with Xcode to provide a way for developers to test their iOS apps without the pain of loading into on to a physical device each time. The Simulator can emulate all manner of Apple Hardware. It ships with whatever the current version of iOS is, but you install older versions as well.
The advantage of the Simulator if you are not developing iOS apps is that it ships with Safari installed. By launching the Simulator and opening Safari, you can test you web apps from the comfort of your own desktop.
A quick addendum to my previous ngrok post. If you are not using subdomains, it can be useful for your app to know what ngrok’s dynamically generated URL is. The simplest way to do that is to set an environmental variable.
I’ve been using ngrok on quite a few projects lately. I’ve written about it before, but in short, it solves to problems for me.
- It tunnels back to localhost from a hostname that live on the net, allowing me to develop for webhooks that would barf on http://localhost:3000
- It provides a valid SSL cert. More and more the platforms I build apps for require HTTPS when talking to an app.
The downside is that it adds another moving part to the process. I’m too lazy for that, let’s automate it!
Everyone has their patterns, here’s mine for starting a new Rails project:
1 2 3 4 5 6
It’s been quite a while since we built Emacs from source on the Mac, but 25.1 has been official release, not to mention macOS (really?) Sierra to muddy the waters, so let’s take it for another spin.
I was recently shown the Best. Chrome. Extension. Ever.
JSONView is a Chrome extension that formats JSON when opened in Chrome. Normally when you hit a URL that returns JSON, Chrome displays a pile of goo. Actually, it just display the JSON as is, but most rendered JSON is not well formatted (and doesn’t need to be, it’s not intended for humans).
JSONView cleans up the formatting and applies syntax highlighting. Better still, it displays any errors it finds while parsing the JSON. If you are developing an API that sends JSON, it’s a great way to make sure what you are sending is valid and, when it’s not, to debug the problem.
It seems like everyone knew about this before me, but if you don’t, you just might want to add your tool box.
Recently (I seem to start a lot of posts with “Recently”), I was on the road needed to access a server that was behind a firewall. There was no VPN and access was limited to a small set of IPs. I could however access another server in that set of IPs. That would let me bounce through for SSH access, but really I needed access from my laptop.
A post or two back, I looked at having BASH detect if I was on my “desktop” (for lack of a better word) or a server and decided the best approach was to hard-code that fact. I casually tossed the configuration in my .bashrc. Was that the right place?
rsync will happy copy files between
servers and will keep the ownership and permissions the same. However,
if you aren’t the owner of all of the files then ownership sync
rsync on the receiving end (which we’ll call server
B) to be running as root. Likewise on the sending server (server
A) if we don’t own the files we might not be able to read them and
again need to be running as root.
root on server A is easy, we can just use sudo:
root on server B requires a little more finesse, we need to
override the remote
rsync command to include
sudo, this is done
--rsync-path path option:
(This presumes you can run
sudo without a password on server B,
things get a little hairy if you can’t.)
Great. Done. But, what if you can’t log into server B with a password?
I’m embarking on a long, long over due project to organize my dotfiles, you know, all those files in your home directory that start with “.” and configure your software. (If you don’t then this isn’t the post or the blog for you.)
There are lots of schemes for storing and distributing dotfiles, and I’ll get to that. But first, I need to clean up the mess of living in the UNIX shell for 30 years. Really.
My goals are twofold: 1) Any time I spin up a new server, I want to be able to deploy my preferred configuration out to it. 2) I want a complete copy of my local machine’s config setting to make it (relatively) simple to setup on a new machine.
These goals conflict.