Vincent Ritter

Hey, I’m Vincent. I’m a dad 👨‍👧, husband 👫 and an independent programmer 👨‍💻 that also freelances.

Browse my blog timeline below and use the menu to find out more.

Timeline Subscribe...

I just pushed out Gluon 2020.3 Build 3 on TestFlight. It includes an experimental image proxy. Read about it here. Just testing this as a proof of concept at the moment and see myself adding extra options on the settings page for this also.

After a bit of experimenting… here are some preliminary results on one image using the Gluon Image Proxy:

This post on Micro.blog, has an image at a size of ~ 689.5KB. That’s not bad. However, most of the time we don’t need the full size image in the timeline. Here is original image of that post.

The image is 1800px wide and 1350px high. However, on a phone screen, which is only around 375 wide (for what I display with padding etc)… we don’t need to load the full sized image.

So, before the image loads on the phone, I pass the URL to the Gluon API including the width that I need, including a small multiplier (in our case *2 = 750px because of the 2x screen density on most phones). This will be device specific.

The API then passes back a URL for me that I can load with the resized image via the Gluon image CDN. This is the image resized for the above post. Note that URL’s are signed so this is the only image you can guess 😋

The image size is… 98.8KB. That’s a saving of nearly 600KB!

I’ll be rolling this out to TestFlight today, so I can experiment with it and get your feedback.

Note that opening images will load the full size image.

Currently working on an image proxy for Gluon that would allow me to resize images, that show on the timeline, instantly and be served via CDN. Going to experiment with it in the next TestFlight build. Useful if you don’t want to server a full size image.

Time for coffee ☕️ and code 👨‍💻

Managed to shave off 60KB from my site with some optimising of CSS and JS. This makes me happy.

Have added conversation.js to my site, thanks to Manton! It works really great. Here are a few example posts:

I used Preact for the JS side and using fetch for the data call.

Super happy with it!

And so it begins… the first version of Gluon 2020.3 TestFlight is coming soon.

Picard.sh Project Diary - The Registration process

It's totally been overdue, but here I am with an update on Picard.

I'm not going to lie, I let this slide a bit after some pressure on getting Gluon out the door and a fair amount of client projects. So, here I am with some progress.

Let's get to it.

The registration process

I spent some time, over the weekend, to work on the registration process. There were a few screens designed already, but they had zero functionality.

The database design was already complete from my past self so all I had to do was write the code and make it work.

It's not complete yet, however it surely is getting there.

Registration is always weird and everyone does it differently. For Picard I wanted something that was quick to get in to, yet be safe to you. Managing your own servers can be tricky and using a third-party, like Picard, sure makes life easier.

However, with convenience comes responsibility.

When you're running a server that usually means you also keep personal information on it. That means that you should stay secure from sign up to deployment. As Picard acts as a front end to all your servers, I don't just want to allow the user to set any password they wish and be done with it. That just opens up headaches with keeping your account secure.

With that in mind, here is the flow of registration I have in mind:

The first two are easy, just set an email and then set your name. For email signup, during the beta, it will check if you have pre-registered or not. Only valid emails and pre-registration tokens can be used during pre-registration. You will get an email with that once I send out the first invites. If you want to set a different email during that process, you're more than welcome to.

Here is a screenshot:

Easy enough to get your started. Not shown is some extra text in the description, when using a pre-register invite link, saying that a different email can be used. You can see a screenshot of that here.

Next up is the Name field, keeping it simple:

This is just to keep it all nice and human. That name can be anything that means something to you. Your actual name is a good start. It will play a role later on. It's a mandatory step.

To note, all data is encrypted in the database, here is a preview from my local machine:

Note that my local, staging and production database all have different encryption keys.

Once that is set, we come to the password selection screen. This is slightly different than what you're used to normally, and I give you a choice of what you want to do.

Two options:

Personally I prefer magic links, but I totally see the need to set your own too. So here I give you an option.

Magic links

If you choose magic links for log-in, you will receive a link via email every time you want to log into Picard. A great side effect here is that you will never know your password... and it constantly changes - so it's never the same.

Password

Some of you prefer to set your own password, and I totally get it! In this case, you will go ahead and enter your own password during registration. Here I am planning to also check if the password hasn't been pwned before and if it's secure. That means I'll check the database at Have I Been Pwned before allowing you to proceed. 1Password also uses this feature to check against "pwned" passwords. To note, the password is never sent to Have I Been Pwned.

On top of setting a password, you will have to enable OTP auth at this stage. This is mandatory when using your own password.

This might sound like a headache... sure, however your and my safety is more important to me.

Of course, nothing ever is totally safe. However we can go some way to make it harder to gain unauthorised access to your account and servers.

More auth options

This hasn't built yet, however I am also planning to add OTP auth for magic links for extra security. This isn't mandatory at the start, but can be set later on in settings.

On top of this, I am also researching the use of WebAuthn. Which basically allows you to use security keys and other methods for authentication where supported.

Back to the registration process

So now that we have the lowdown on options, here is a screenshot of the password preference screen:

I highlight the magic links, as they're convenient. Gently nudging you in that direction. Depending on what you select, you'll go to the next steps. Which are yet to come.

One note on registration, once you entered your email and advanced to the next step you're already logged into the account automatically. So if you decide to leave and come back later, you will be redirect to the correct registration process. So I'll double check which step you're at and redirect as needed.

Next steps

That's as far as I got over the weekend. It's been fun working on it so far. It's also fun to work on the frontend and backend at the same time, which is a nice flow. With Simple Schedule I built out the frontend first and then the backend. This worked fine and gave me a clickable prototype... however it also introduced wasted work for features that didn't make it.

For this week I am planning on finishing the registration process for both magic links and password setting. I'll probably also then work on the login part.

That's it for now.

For the last few days, I’ve been logged out of all thing Apple App Store. That means the TV asked me to sign in again, then Apple Music, then App Store on the Mac… Then App Store on the phone… seemed never ending to repeatedly having to put in my password. Hope it’s over.

Spent a few hours working on Picard.sh today. Felt good. Going to do a small write up tomorrow about it.

Started the slow task of moving transactional email provider from Mailgun to Postmark. The UI is simply great and lovely to use! That’s a win for any service I use.

Already moved Picard.sh and next up will be Simple Schedule.

It’s becoming more important to me, lately, that services and apps work cross platform. That should be the norm. Just like driving on the road - you can use the road with any vehicle you so choose to.

Here is my Android home screen:

Had a bit of a few Android days at home as of late. It’s nice, although feels cluttered at times. Tried Apple Music… and I can’t stream to my HomePod. Why? Frustrating. In fact, the HomePod is pretty useless in that case.

Apple should copy this from Spotify:

I’m listening on the Mac, and it’s showing on the iPhone and I can control it from the phone or Watch. I know they have this AirPlay 2 magic… but that just doesn’t do the trick nicely at all (especially from the Mac side).

Didn't manage to record for my podcast this week as I was finishing a client project and doing a few other family things. Should be back on track next week.

I was looking at new headphones recently, as my current ones give me a headache/ear ache (from noise cancelling). So it’s good to see a rumour for AirPods X there somewhere. Gonna hold out for a bit and see if that comes true.

iOS Home screen. Decided to add sound apps into a folder. Kinda nice.

In good news… I have completed my big client project. All went really well. Looking forward to slowly winding that down and send in that invoice haha. Onto the next project 🥳

This quote on Daring Fireball hits the nail on the head of something I’ve been thinking about a lot lately:

Larry taught me the value of taking the user’s point of view; using heuristics to work magic; to look at all the cases. Much more than inventing copy and paste, he invented it as a writing tool, not a code-editing tool, for people who didn’t understand computers.

I do want to write a longer post about this, however it needs more thought before I fully publish my article… but when I look at the IndieWeb movement, I just think to myself: “Most people don’t care about what it does. It just has to do the job, be quick and easy to use and not overwhelm people with technical jargon”.

I see many buzz words flying around, but they mean nothing to anyone outside of the “tech” circle. As a user I just want to set up an account, have a nice app to use, and get using. I don’t care what is behind it, I don’t really care about those technicalities… just give me a good product and a pretty website, and/or app, that works well and gets the job done.

As a user I don’t want to set up “Web mentions” or “Pings” or whatever else. I’m a consumer after all, not a coder (and I don’t mean me personally, but as a “I’m a normal consumer looking for something better").

Technology should be invisible to most people. It should just work.