Apple has made an announcement that by 2030 they’re entire business, including the Macs and iPhones you purchase will be carbon neutral. This is a great step in the right direction and I’m glad to see Apple taking the lead.

Sometimes I get disappointed with macOS and think that my next computer may be a  Thinkpad running Linux. But it’s moves like this that help keep excited about supporting the company. Between the ARM Macs and climate change leadership, Apple’s future is looking brighter than ever.

I’ve been trying to master the tools I use on a daily basis better. Some of that is learning how to do things with them that I don’t know how to do them presently.  For example “validate and prettify this JSON”.  Usually it’s a quick trip to some json linting service online, copy/paste/validate. I know it can be done locally and I’ve done it locally in the past, but muscle memory takes time to retrain. But if I can manage it one task at a time, I’ll be a pro in no-time.

I’ve been trying to debug an issue when my Apple Watch where  announcements from Siri cause Overcast to pause. The only way to resume it is to go back into Overcast and hit play.

Before my most recent run, I synced some music on to my watch and the experience with Runkeeper was much smoother. As expected, when pace/time announcements start the music fades to half-level then fades up to the regular level when siri finishes as expected. So it seems like the music pausing may be a bug in Overcast’s handling of siri announcements or Music having access to some APIs that regular devs don’t.

On second thought, most podcasts are spoken word and listening to Siri and your half-leveled podcast simultaneously would be a poor experience, so it’s makes sense that it pauses playback when Siri starts. However, it would be nice if it resumed when Siri finished.

My second run with Apple Watch was better. Not just the run itself, but using the Watch while running was a lot smoother.

In my first run with the Watch, I lost audio when my Airpods appeared to have died midway through and each runkeeper pace announcement via Siri would stop music. This time my Airpods made it easily, but my music still paused every 5 minutes.

I believe the issue with my Airpods in my first run wasn’t my Airpods, but rather the podcast I was listening to was only partially buffered from iPhone. By my second run, Overcast and my watch have had plenty of time to sync and plenty of audio for my run.

The pausing audio issue I believe to be a bug with runkeeper. To test this, for my next run I am going to try running with just the Apple Workout or Nike Run Club app and see if audio resumes after callouts. If it doesn’t, then there’s potential that it’s an Overcast bug, and I’ll need to try with the stock Music app (and sync some music I’d like to run to!).

 

I went on my first run with my Apple Watch yesterday. It was a short run as I haven’t run in a while and need to build my capacity back up. First impression is that running without my phone is so nice. Losing the extra weight, not needing to worry about accidentally setting off the SoS to call the cops while blindly fiddling with volume control at 5am (true story), and not needing my SPI belt are all great. 

I usually run listening to music (the Anjunabeats Worldwide Podcast) via Overcast and Runkeeper set to announce times / pace / no music (because Overcast is in control). I imagine it’s because a lack of processing power on the Watch, but Runkeeper will pause music to announce times every 5 minutes, but it doesn’t resume immediately afterwards. I have to manually press the dock button and hit play to start music again. Not sure if this is a bug with Runkeeper or not.

The other issue I ran into was my AirPods disconnected from my watch mid-run when my Watch realized my iPhone was out of range. This caused me to loose all audio as I couldn’t get them to reconnect.

After my run, I usually share immediately on twitter and then look at my phone while cooling down on the way home. No phone means no immediate twitter sharing and no staring at a cell phone. Walking home without feeling the urge to look at my phone and just look around was a nice change of pace I could get used to.

Bringing a new piece of internet-connected technology into your life requires an adequate amount of thought. And after a couple years of thinking about it, I finally decided to get an Apple Watch. Usually there’s no need to blog about a consumer electronics purchase, but I feel like the Apple Watch is different. Its capabilities and role are more intimate.

That is, I’m not getting one to tell me the time – I have a couple of great watches that work fine. No, I’m getting the Watch because it can help remind me to focus on me and the long term. If properly utilized it can aid me in my quest for a simpler, healthier life.

The promised sleep tracking, combined with the package of simpler features is what finally pushed me over the edge to purchase one. I’d love to be able to use the EKG feature, but it’s not enabled (yet) on Watches sold in Japan.

Sleep Tracking

Reading about the sleep tracking feature online, it seems that it’s less focused on the minutia and more focused on the big picture. Get you to bed on time as planned, so you get your hours in, and the rest will work itself out. Focus on the basics.

While I usually get 7-8 hours of sleep a night, with a toddler, my sleep or wake time are not entirely in my control. Having a record of my hours slept and then being able to corollate it over time to how I feel will be powerful.

Haptic Alarms

One part of my sleep schedule that is partially in control is my wake time. Ideally I’d like to get up around 4am consistently. This is easier in the summer in Japan because the sun rises around 4:30am and it’s hot by 6am. However, I’m unable to use an alarm that makes noise, as it’ll wake everyone else in the house up. Using an alarm that doesn’t make noise, but just vibrates so I can feel it is a game changer for controlling when I rise each day.

AirPods + GPS

Having a built in GPS and being able to sync music / podcasts to my watch will make it easier to go for a run in the morning. No more fiddling with my phone, wearing a bag to hold it or anything. Just grab my keys/id and go.

ApplePay

Full support for ApplePay on the Watch means when I’m out for a run, I can stop by 7-11 to get an iced coffee without fiddling with cash or my phone. It also means that even if I forget my phone (or choose to leave it at home), I still have my credit cards / transit cards, everything with me.

Even if I manage to wake consistently at 4am, I’ve still got to use that time efficiently. Waking up by my iPhone next to me is a quick way to lose my faith in humanity before getting out of bed each day.

I’ll end with a few things that I hope the Watch will encourage.

  • Consistent wake and sleep times. I’m shooting for an 8pm ~ 4am schedule. When my son is gone, the 8pm bedtime goes out the window.
  • Increase Water Consumption: I tend to slip on coffee for too long and not drink enough water. Simple reminders to nag me to drink my water.
  • Increase movement during the day: I’m a programmer and when I get in the zone I don’t get up unless I have two. Fortunately my workplace lets me get in the zone pretty good almost everyday. Unfortunately, I’ll realize sat down after lunch and haven’t gotten up once until quitting time.
  • Running: My eternal goal – become a regular runner. I was a regular runner for 3 months just after Leo was born. It may have been because I was sleep deprived and my brain couldn’t talk it’s way out of running. But it also may have been that I was always up at 4am anyways.

It arrives tomorrow and I am giddy.

I bought a new (shorter) domain for my new email address. One advantage of migrating away from gmail that I hadn’t anticipated is how much calmer I feel.

You see, Gmail technically supports IMAP, but it’s more of a shim. You’re not really supposed to use IMAP with Gmail. And as such I never felt comfortable using a regular email client, instead opting to check mail via the web-app.

Checking mail via a browser is fine but being in a browser switches your mind to a different context. Browsers are meant for consuming. The entire internet is just a simple cmd-T away. So “checking email” became a mental excuse to open my web browser. And then Twitter. And then Hacker News. And then Reddit. Oh, I wonder if I got any new email? And repeat.

Now with a provider where IMAP is a first class citizen, I can use Mail.app again. Mail is set to be pulled in once an hour. No more temptation from a web browser. And an unexpected sense of calm.

I’m back in control.

I’ve been using my gmail account since a few months after the beta started. I’ve moved a dozen times since then, but my email stayed the same.

However, over the years Google has lost my confidence that they’ll do the right thing and do no evil. It’s for this reason I don’t use their apps, don’t invest in tweaking gmail, or even (especially) sync my contacts.

As a Mac user for almost 20 years, I’d like to use iCloud for my email, but I can’t use custom domains with Apple. While I don’t foresee Apple losing my trust and confidence, I can’t be sure.

Tying my email to a third party domain will lock me in to their ecosystem, for better or worse. Moreover, I could lose it all in an instant by the whim of an algorithm with little to no recourse.

With Gmail, I’m not the customer, the advertisers are. And because our interests are not aligned, I have no idea how my data will actually be used.

What to do?

The obvious answer is to move my email to a domain I own. Then find a provider that supports open protocols and that I pay at a regular interval.

I’m leaning towards Fastmail. They’ve got a nice detailed migration guide, I’ve been a customer on the business side for a number of years, it’s time to renew, and most importantly their systems behave in ways that I expect.

The main blocker isn’t even money, it’s updating each account that uses my gmail as a login to my new address. Lock-in, albeit defacto and of my own doing, is a bitch.

The mantra in bootstrapping circles for the past while has been “charge more”. And the best way to charge more, over time, is a SaaS. So it’s natural that most bootstrapers default to a SaaS pricing model when starting their new projects and companies.

I’m no different. I build web-apps professionally and have for the past 10 years. Web apps are my bread and butter.

But when I compare my successful SaaS projects to my successful desktop app projects, no matter the metric, I’ve always made more when I charge less and charge it once.

And since I’ve been so focused on SaaS and this charge more mentality, I’ve automatically dismissed ideas that I had that weren’t SaaS.

After attempting to build a number of web apps independently I’ve mostly stopped midway through. The slog of getting the basics perfect, managing servers, dealing with recurring payments, it’s too much like my day-job.

And so I find myself considering going back to my old bread and butter for side-projects: native apps for the Macintosh.

So far I’ve got a few ideas for small utility apps. The ones I’m most interested in are the ones that fit in the open web and apps that can help increase privacy for its users.

It’s been a breath of fresh air and I’m excited to be having fun making things again.

Django has a nice security feature that verifies the request HOST header against the ALLOWED_HOSTS whitelist and will return errors if the requesting host is not in the list. Often you’ll see this when first setting up an app where you only expect requests to app.example.com but some bot makes a request to <server ip address>.

While it’s not strictly harmful to add your server ip to your ALLOWED_HOSTS, in theory, it does allow bots to easily reach and fire requests to your Django app, which will needlessly consume resources on your app server. It’s better to filter out the requests before they get to your app server.

For HTTP requests, you can block requests by adding default_server that acts as a catchall. Your app server proxy then set its server_name to the a domain in your ALLOWED_HOSTS. This simple configuration will prevent http://<server ip address> requests from ever reaching your app server.


// default.conf server { listen 80 default_server; return 444; } // app.conf upstream app_server { server 127.0.0.1:8000 fail_timeout=0; } server { listen 80; server_name {{ WEB_SERVER_NAME }}; access_log /var/log/nginx/access.log access_json; error_log /var/log/nginx/error.log warn; location /static/ { alias /var/app/static/; } location / { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Request-Id $request_id; proxy_redirect off; proxy_pass http://app_server; } }

However, once you enable SSL with Let’s Encrypt, despite the fact that they matching by host, as there is only one SSL server configuration by default, it routes all https traffic to the same host. What this means is that while requests made to http://<server ip address> will continue to be blocked, requests to https://<server ip address> will begin to be forwarded to your django app server, resulting in errors. Yikes!

The solution is to add a default SSL enabled server, much like your http configuration. Thee only tricky bit is that all ssl configurations must have a valid ssl certificate configuration as well.  Rather than making a self-signed certificate I reused my let’s encrypt ssl configuration.

// default.conf
server {
  listen 80 default_server; return 444;
}

server {
  listen 443 ssl default_server;
  ssl_certificate /etc/letsencrypt/live/{{ WEB_SERVER_NAME }}/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/{{ WEB_SERVER_NAME }}/privkey.pem;
  include /etc/letsencrypt/options-ssl-nginx.conf;
  ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

  if ($host != {{ WEB_SERVER_NAME }}) {
    return 444;
  }
}

By adding a default SSL server to your nginx config your server_name settings will be respected and requests that do not match your host name will no longer be forwarded to your app server.