Vincent Ritter

Hello, I'm Vincent. I'm a dad, husband, geek and an independent software engineer that also freelances. Check out the apps I make, personal projects I'm currently working on, websites I made and other things like my blog posts and thoughts.

Trying out a new seating arrangement at the desk. I feel the chair drains my energy a lot and also doesn't give me room to... well... move. Anyone else using a gym ball as their chair? It's still weird and new, so I'm going to have to stick with it for at least a week or two.

I spent nearly all day exclusively on Gluon. It's at 3 days to go until the last TestFlight runs out. I'm feeling somewhat pressured. I'm thinking of shipping of what I have on Thursday evening or Friday morning. It will have lots of features/functionality missing that is in the last build, however I think it's for the greater good in the long run.

I was thinking about this the past few weeks as it dawned on me that I will never have it ready in time with everything I had. Probably not the best thing to take away features/functionality...

After that, I will keep shipping updates as and when they are ready. All my TestFlight slots are full already, so I want to thank everyone for using Gluon! I'll be opening more spaces in a few weeks to give me some space to add a few more features/functionality.

I'll write a blog post about progress in the coming days. This, however, was important to say.

Taking my girls (daughter and wife) on a mini trip over the weekend, starting today. Trying to bring some calm to our lives. Had to stop working before falling into a never ending cycle of burnout... good decision.

I'm thinking of using TypeScript in future, instead of JavaScript. I think it would save a lot of headaches.

17 days to go until the last build of Gluon runs out. No pressure! Hopefully I will have good progress over the weekend. Let's see.

The app already runs at least 3 times faster than the old one, so I'm pretty happy about that. Although I'll have to start adding all the features, that the old build had, back in. Worth it in the long term.

What a week! Monday and Tuesday was really busy getting something live. Then I've been ill since Tuesday until now. Couldn't do anything except stare at my screen and write one or two lines of code. We were all ill this week, so we were probably just passing it to each other.

Now to see how I can catch up for missing 3 working days... so many things on my list, so many things on my mind. Perhaps I'll just take it easy. That's probably the correct approach. Next week is another week to fight.

Gluon - a new beginning

It's been 5 steps forwards, 6 step backwards, a few missteps and then back to square one. That pretty much sums up the development for Gluon the past few weeks.

It wasn't as such as a standstill, it was more a question of how and finding a perfect middle ground. Not to mention coming to the realisation that I am only one person, that also has clients, and that I won't have time to learn big new frameworks from scratch without spending considerable amount of time. I want something I can develop using a workflow I know and am comfortable with. I also want to be reactive to change and be able to make changes with ease across both platforms, reasonably quickly. I don't want to duplicate my work and I certainly don't want to be behind the drag curve (aviation nerds will like this saying!).

I realise that I said a few things about my gripes with certain frameworks and workflows, but the truth is... I work with them every single day! I feel like I'm in a unique position to make this work for me and get better at what I can offer for clients and of course for pushing forward with my very own ideas that I want to work on. So for me the developer happiness is that I work and continue to improve with the tools I work with every day... even though sometimes they don't line up with my personal standards or just annoy me.

Anyway... there are personal objectives and views and then there is reality. I'm happy to accept reality.

So, I can only apologise to be a flag in the wind the last few months!

A new beginning

The first version of Gluon ran across multiple platforms using React Native, which allows you to build native apps using Javascript. That's pretty cool (notice the change of tone).

Unfortunately version 1.0.0 was riddled with wrong doings since step 1. The official way to install React Native and get started is using a third party framework called Expo. Expo, on paper, is amazing. However, once you realise what it actually installs and how it locks you in... you don't want to ever touch it again. Last year I built a React Native application for a big client, using Expo as the starting point. It's a regret I/we have to live with! Sometimes the "quick" way isn't the right way, and it's certainly true here.

Gluon 1.0.0 weighed in at roughly 26MB on iOS and Android... and that's out the box!!! I haven't even added any single line of code at that point. For me this should have already thrown a red flag.

When using Expo, they'll add loads of unnecessary Android permissions that the app wants out the box. Yup, you can remove them... but the problem was that there were still many areas of doubt! This shouldn't be the default out of box experience. I don't need to know any precise information on location, or phone status, or access to contacts and and and. I'm not building a shady app. I'm building an app that users can trust!

Anyway, I took time to work on a super clean React Native build using the "old" way of installing a project. The installation and getting it to run was surprisingly easy. However setting the right direction on how I wanted to code and keep it all modular and easy to work with took a few trial and errors. It was painful and I did loads of researching!

I'm going to share some screenshots in a minute, which has some code running already, however the most important part is the build size of the app...

My pure native iOS Swift version that I shared a screenshot of the other day, weighed in at 12.8MB out the box with a few navigation controllers and the login screen. Not bad! Less than most websites for sure, ha!

Now, I've got the build down to 3.8MB! This makes me happy! I know that many people probably don't care about things like this... but I do!

Introducing the start of Gluon 2.0.0

Version 1.0.0 was a playground... I should have called it Version 0.0.1. Anyway, 2.0.0 is fitting and it marks a new beginning for Gluon. One that I'm happy with and I'm hoping that users will be happy with too.

I can re-use most of the codebase for Version 1.0.0 and bring it across to make progress quickly, however I'm reworking the lot. It's a great opportunity to do just that. Version 1 was built super fast in pretty much a solid one week (for most of it), which served its purpose! The code isn't bad, but it's not the best it can be. Sure, nothing is perfect but I can see how it can be improved greatly. Developer happiness, right?

There will also be finer enhancements with the UI and a better integration into the real native navigation controllers for both platforms. Version 1 used something called 'react-navigation' which is the recommended standard (again). Unfortunately it only emulates the navigation behaviour found on both platforms, there is nothing native about it. That means that speed and, most importantly, accessibility was and is, crap! Well... no more. Now I'm using the excellent 'react-native-navigation'. It was a bit painful to set up but well worth the time!

Screenshot time

Now that I hopefully set the tone... here we are at the humble beginnings once again. I spent the weekend working on getting the base screens set up, with their real navigation controllers. I had a few problems, but I finally managed to get past that hurdle... build and compile errors and what else not.

Here is the tab screen, after log in. Yep, get a shock, there is nothing there!

Android left, iOS right. Notice the difference in the tabs on Android? Yep... those are native and react as you expect on Android. That made me happy!

Something that wasn't possible before was listening for "viewDidAppear" events or "viewWillDisappear", you'll know them from native iOS development. Pretty handy! Out the box you would have to listen for "onFocus" or "onBlur" events on the window DOM, which was painful and never really was that good to rely on to clean up stuff like cancelling network calls or other things.

I also now have the ability to cache the current screen, the whole lot of it. So when you come back to the app, after it has been killed in the background, you'll get the most recent cached version which is followed by whatever I have to do to fetch updates and refresh the UI in a meaningful way.

With this set up, I worked on the login screen next - I took the existing design and ideas and tweaked it ever so slightly. I'll probably make it a bit more sparse.

The colours at the bottom are the Micro.blog shades of orange. However, I'll probably just create a small button under login that says "Create an account" or something easy like that.

That's the design done, so now I just need to reintegrate all the API calls and logic. I already have a solid way of doing it, so I'll probably use most of what I did.

Next steps and timelines

The next step is to work on the login and a nice way of displaying what is happening as you log in, something that I didn't really think about too much in v1. Hoping to have this done in the next few days including creating a solid foundation for calling the Micro.blog API.

Then, step by step, I'll be working on getting everything (mostly) into the app again. I'm conscious that the current TestFlight build runs out in about 26 days... and that there is no version for Android available at the moment.

It's my hope that I can get a build out that displays the timelines nicely and profiles within a few weeks. It won't have 100% of the functionality as per version 1.0.0 though. However, I'll be able to build them out relatively easy. Replying will probably be missing, but not for more than a week or so. Settings will also not be there for now as I rework some of the UI logic that plagued v1.

Anyway, just a huge thanks for all the nice emails and notes I received. I'm hoping that the app makes a meaningful contribution to the community in the long term.

Thanks for reading.

Sooo... after spending countless hours and one late 05:00 AM headache to get a websocket (Rails Action Cable) to run on a production/staging server with Passanger... it turns out all I had to do is set my allowed domains in the production.rb file:

config.action_cable.allowed_request_origins = ['https://some-domain.test','https://some-other-domain.com']

Any NGNIX experts out there that can point me the correct direction to secure a web socket connection which is being served by a Rails app? The app is already secured under 443 but getting the 'wss://' to work is proving difficult.

Made a few tweaks to my "Code Challenge" page. As I seem to be working on several projects at a time I wanted to show them off a bit more nicely. I renamed the section to Projects too as it seems more fitting. You can click/tap on a project to go to the specific project page. I need to do a bit more work here to display specifics like URL's, TestFlight links etc.

Of course, redirects are working nicely so no inbound links that I know of are broken.

I seem to prefer the dark mode part of my site, so I might make it the default. It currently switches depending on the local time... or you can manually trigger it in the sidebar...

And to celebrate, a secret project that I started last night just to scratch that itch again... more on that next weekend though.

Close