Video on blog.iankulin.com

Web Development Overview

Mon, 05 Feb 2024 00:00:00 +0000

I don’t often just link to someone else’s content, but I was really impressed with Brad Traversy’s “Web Development In 2024 - A Practical Guide” video. Apparently he does these every year - it’s just a really comprehensive overview of Web Development pitched at beginners.

Complicating the Temperature API

Wed, 28 Jun 2023 00:00:00 +0000

I’ve been slammed with other work, so my web dev learning has fallen well behind. Luckily, the YouTube procrastination algorithm noticed this and suggested I watch a video from CodeWithCon titled Learn Backend in 10 MINUTES.

Since I was watching a video of a guy learning to land a C152 at St Baths (a skill I do not need) at the time, it was hard to argue with myself that I didn’t have ten minutes to learn all of backend programming.

I mean, all of backend programming in 10 minutes is a big claim, but the video did do a surprising good job of simple REST APIs in Node using the Express framework.

I abandoned iOS programming a year ago when I started to think about the sort of applications I wanted to develop, and saw they would need to run against cloud databases, and so I was going to have to learn backend web dev at some stage anyway, and if so, learning that, then writing the front-ends for web seemed like a lower friction, and wider audience approach.

I have sort of created an API to solve my temperature logging problem. A Python script runs as a cron job every 5 minutes on a VPS, calls a weather API, parses the json and drops the values I want into a text file on an NGINX server which can be called with a straightforward GET.

While that was great to learn a bit of Python, it’s not pretty, or standard. It does solve the problem I intended (I wanted that weather data for three servers running at home, but didn’t want to hammer the weather API I was using for free) it has a few other problems. As the cron job on the VPS runs each five minutes, the data there can be up to five minutes behind the API, and since the cron jobs on my servers are running on the same five minute intervals, and the call to the Australian VPS is quicker than the API call to the US based API, I’m always returning the VPS data from five minutes ago - so now my data is up to ten minutes old.

Does that matter for this application? No, but the whole exercise was for learning, and this is a good enough reason to improve it my making it even more unnecessarily complicated.

I think my new system will be that the homelab servers will still poll the VPS, but the VPS will be a Node.js endpoint. When it receives a GET from one of the servers, it will check the age of it’s current weather data. If it’s less than a minute, it will return that, if it’s older than a minute, it will call the weather API, store that and return it.

Apart from reducing the latency of the outside temperature data, this has a couple of other benefits. The first is that my VPS won’t go on for ever requesting the weather API data after I’ve reloaded the operating system on the home servers and completely forgotten about this project. The second is that the temperatures in the data I’m getting back look like they only change every 20 minutes, so probably they are stale before I ever get them from Open Weather. There are live weather station web pages that I could scrape for better data, so doing things in node on the VPS leaves a good option open for that future improvement.

To chunk the project down to really small bite sizes, I’ll to it in two parts.

The first will just be to replicate the current system - return a text file when receiving a GET - in Node. That way I will have dealt with the issue of running Node behind NGINX on the VPS.
The second part will be to expand that to call the weather API from inside the Node program when it’s needed.
A possible third part would be to convert it all to JSON instead of text, and then deal with that in the Python scripts running on the servers.

That’s the plan.

CSS for Beginners

Thu, 15 Dec 2022 00:00:00 +0000

I mentioned a couple of days ago that the ZTM webdev course was skipping forwards too quick and that it would need to be supplemented. For CSS, I think the supplement for me is going to be this series from Dave Gray.

Towards MVVM

Sat, 03 Dec 2022 00:00:00 +0000

On one of the more mediocre episodes of Fireside Swift, McSwiftface and Zach talk about the SOLID principles of class design, although I don’t hold the principles as the article of religious fervour that many interviewers apparently do, they are a useful touchstone for considering class quality. OOP had been in swing (in a commercial way) for a few years by then - I was writing in Delphi and C++. The spaghetti code era was a long way behind us and the idea of separation of responsibilities was well established.

I have been thinking about architecture a bit anyway - the introduction of Core Data into the #100Day apps I’m up to (day 63) means that there’s complicated looking code scattered around my views. In the cs193p lectures, MVVM is right near the start, and I made some early forays into it, but so far no talk of architecture in 100Days (although I know it’s coming soon.

I have certainly had the experience before of needing a layer between my apps and the database tech so they can be swapped out, and it’s basically a reflex to me to always wrap any commercial external code I’m introducing in any reasonable size program to abstract it a bit and make the (likely) task of having to replace it in the future a lot easier.

Once again, YouTube serves me up a timely video.

When I watch this, I can see why Paul Hudson might have left it for later in the course. There is a lot of complexity. It’s not simple code, it’s scalable code. This is good for real life apps, but it does not follow that it’s good for learning programming.

Calculator

Thu, 29 Sep 2022 00:00:00 +0000

The app I’m working on currently (for multiplication tables practice) has a number type keypad and display a bit like a calculator - but for entering the answers. It’s been quite fun to think through all the little problems to make it work how you’d expect, so I was quite interested to watch an iOS Academy video where Afraz Siddiqui builds a partially finished SwiftUI version of the iOS Calculator app.

It is a great example for beginners to see the power of building views quickly in SwiftUI, but the most fun part for me was thinking of all the edge cases that would hadn’t been dealt with in his quick build out of the logic (which wasn’t the point of the video).

A couple of times I’ve thought about building copies of existing Apple iOS apps. I think part of the appeal is that the design work is done for me, so I’m just thinking about under the hood. Long term, I need to know more about design and to be better at it - I bet there’s a Meng To course that would be a good starting point.

Gitting up to date

Tue, 27 Sep 2022 00:00:00 +0000

I’ve started the habit of branching my code for each feature or batches of features. This is not really needed, I’ve developing solo, and the code on main is not in production. I could just go on committing, but part of my process is about becoming competent with git.

There are a couple of git commands (merge and rebase) that mush code between branches together in different ways. The video below (from Manuel Lorenz at Academind) is a particularly clear look at these two commands.

The discussion that follows is essentially just a re-hash of the video above, so if you think you’ve got it, you can leave now!

Here’s the situation we start with. A “feature” branch was created at the point in time that the most recent commit on the master branch was “m2”. A couple of commits have been made to the feature branch, but meanwhile a further commit has been made on the master branch:

So, what are the options now? (this is just a rehash of the video above in my words, so if you already watched that, you may leave :- ) I’m going to use “master” in my discussions here since that’s what Manuel uses, but if you’re new to git and you’ve only ever seen “main” - they are just different names for the default branch, “main” is the current (and slightly better) preference for that name.

Merge

We could checkout the master branch, and merge feature into it with

git merge feature

That works, and our commit history for the master branch will look like this:

M1 - M2 - F1 - F2 - M3 - Merge

Squash

To bundle up the feature branch and bring it across to master, we can (from the master branch) do:

git merge --squash feature

That add all the feature changes to the current branch, but they’re not committed yet, so we’ll also:

git commit -m "add feature"

The history of the master branch now will be:

M1 - M2 - M3 - add feature

So this is sort of neater, instead of a chronological history in the commits, we’re conceptually saying the feature work was all done in a single commit after the M3 change. But… what if we wanted to keep the feature commit history?

Rebase

Just to recap, although our master branch is up to m3, the feature branch was based off m2. So if we had a look at the history of the feature branch (using git log) it looks like this:

M2 - F1 - F2

Rebasing it will look at the changes in feature then apply them to the current m3 commit in master. If we change to the feature branch and enter:

git rebase master

Now the feature history will be

M1 - M2 - M3 - F1 - F2

That’s sort of cool and all, basically the code in the feature branch is in the state that master would be after we’ve joined them back up, so we can go ahead and test and so on. But we haven’t actually joined up feature and master yet. To do that, we could to checkout the master branch, and rebase it from feature with:

git rebase feature

Then master will have the same history as feature: M1 - M2 - M3 - F1 - F2 That can just be committed and we’re good to go. Since the whole commit history is now in the master branch its fine to go ahead and delete the feature branch.

Gotcha

If you’re working in a team around a shared repository, it makes a lot of sense to rebase your local project from the current main/master in the shared repo. That way you can test for any problems your code might have with the current version, but, it’s bad form to rebase any commits that get pushed up. A good explanation for why this is can be found in the git docs - scroll down to “the perils of rebasing”.

Instead what we should have done in the example above if we were planning on pushing the master would have been to rebase our feature branch as we did, but then change to the master branch and merge the feature branch in with

git merge feature

iOS Academy

Mon, 26 Sep 2022 00:00:00 +0000

A YouTube channel worth subscribing to is Afraz Siddiqui’s iOS Academy. He does a great videos on iOS development. My favouriets might be the shorter focussed ones, like this one on the new SwiftUI chart views.

Before SwiftUI

Wed, 14 Sep 2022 00:00:00 +0000

I’m on Day 26 of 100 Days, and didn’t grok the dates on my first read through, so I’ve read a couple of other explanations and sat down with a coffee and thought I’d see what YouTube had for me on the subject. I seen a few great iOS Academy videos, so this one seemed like a good choice.

I haven’t seen enough to say if it is a good or great explanation of dates, calendars and date components in Swift yet, but man, getting to the stage of writing useful code when using storyboards and UIKit takes a while! It’s literally 3:42 in to the video before there’s enough infrastructure done for “hello world”.

Takeaways: (1) Watching the launch of SwiftUI must have been mind-blowing. (2) I super appreciate the existence of Playgrounds for learning Swift.

Sometimes the Gold is in the Comments

Tue, 23 Aug 2022 00:00:00 +0000

I’m still not 100% clear on @ObservedObject v @StateObject. So when YouTube offered up this video, in which Paul promises during the intro that I’ll understand the data bindings by the end, I thought it would be the video for me.

I guess I should really have twigged that I’d never heard of @ObjectBinding, but I pushed on to the 12 minute mark when he imports the Combine framework. Hang on, what’s that?

Checking out the comments, it all becomes clear.

Sadly, it’s a page down in the comments, when it’d be great to be pinned to the top.

When we’re publishing content in a tech field that’s changing, there probably is probably some benefit to tagging it with versions - for example, my post on git is sort of useful now, but in three years? Who knows. Like this video of Paul’s it may be unhelpful and confusing.

I’ll put some thought into how I might do that. Going back and updating things is probably not realistic (this is certainly the case for twostraws’ videos - he’s prolific), but branding content with the versions of things might be. Wordpress dates content at the bottom of the post (on my current theme) so that would give some future traveler some chance, but the more novice they are (and currently my understanding of these topics is only helpful for novices) the less likely they are to be equipped to translate the date into the likelihood of the content being outdated. Perhaps I can use tags somehow. I’ll think about it.

CSS Intro

Thu, 18 Aug 2022 00:00:00 +0000

When I wrote my last commercial HTML (in 1996 lol) I’m pretty sure there was no CSS. It was the land of textured backgrounds, blinking scrolling text, “under construction” gifs, and links to gopher URLs were not uncommon. So this is an area I need to update my skills a little just to carry on a coherent conversation in the developer world.

I’ve bumped into a couple of Tech With Tim videos recently, and I really liked his CSS intro for “Non-web developers”.

iOS Academy

Mon, 08 Aug 2022 00:00:00 +0000

I seem to consume a lot of iOS Academy videos with great, short (< 10 minute) explanations of various Swift iOS programming topics - particularly little UI topics, like this one on the Grid View.

I really appreciate the generous content provision in the Swift and iOS development community. Perhaps this is the same for lots of technologies, but for someone who started programming pre-internet, it’s a stark difference to how I used to learn - so many magazines, and so many 2" thick books.

MVVM Explained

Sun, 07 Aug 2022 00:00:00 +0000

The first nine minutes of this video from Emmanuel Okwara finally gave me a clear understanding of the difference between MVC and MVVM.

In both MVC and MVVM the data & logic (Model) are separated from the part that the user interacts (View). Usually the View is a screen with controls and so on, but that’s not compulsory - for example a voice mail app interface would be all audio and DTMF. The point is that in both, the user interface (view) does not mess directly with the data (model) - it has to go through some sort of gatekeeper.

The new understanding I got from Emmanuel is that in MVVM, the View Model does not know what is in the View. It does not alter the view, just broadcasts that there’s been a change and lets the view go ahead and update itself. It makes sense that this would be the paradigm for SwiftUI’s declarative interface style, and is also (I imagine but actually have no idea) the basis for React.js

One thing Emmanuel mentions that I’m not clear on is that each View will have it’s own View Controller. Currently all my tiny apps have had one view in the SwiftUI sense. I have pulled out sub views, and some have had views within views - for example with the Navigation View. So I guess my question would be, “What constitutes a View in MVVM?”

I noped out at the nine minute mark as soon as Interface Builder showed it’s face. I’m an iOS15 SwiftUI baby - I will, eventually, need to learn the old magic, but competence developing iOS apps using SwiftUI current methods is the MVP.

With this understanding, and having finished lecture 4 from the cs193p series, I think a good project for today would be the simplest possible MVVM app with the correct separations and bindings.

Xcode Tour

Sun, 24 Jul 2022 00:00:00 +0000

If you need a solid tour of the basics plus of Xcode, this is a great video from Karin Prater. Its the first video in her “Design-oriented course on SwiftUI”.

Gitting Started

Wed, 13 Jul 2022 00:00:00 +0000

One of my early goals was to get in the habit of using version control with Git/Github, and I’ve got that sorted out today. My source was this excellent, very clear video from Gwen Faraday. I highly recommend it if you are just starting.

It possibly helped that I’m also on mac, so I didn’t have to deal with the “or however that’s done on your system” type problems. Also, where things didn’t work as expected, the explanation about what was being done was clear enough that the problem was solvable. For example, the push command Gwen used was:

git push origin master

but GitHub had defaulted my initial branch to “main” rather than “master”. Easily fixed since she immediately explained what both of those modifiers were. The only other tiny bit of troubleshooting was that my git global config wasn’t set up, so my commit was followed by a big message pointing out that my real email address wasn’t used for the commit:

 Committer: User Name <username@Ians-MacBook-Pro.local>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly. Run the
following command and follow the instructions in your editor to edit
your configuration file:

 git config --global --edit

After doing this, you may fix the identity used for this commit with:

 git commit --amend --reset-author

It didn’t make any difference - the file I’d created locally pushed up to the GitHub repo just fine. When I did follow those instructions to edit the file, I suddenly needed to know how to use Vim (hint: “i” to go into insert mode for editing, then “:” for command mode and “x” to exit and save).

The only real complexity in the whole process was generating the SSH key and saving that on GitHub to allow the push from your local directory up to the GitHub repository.

Ignoring that, the process was:

Creating the repository via on GitHub
Using git clone to download the repository to the local machine and set it up for tracking in git
Edit/create the files, however. Gwen used Visual Studio code, I used my tools
Check status with git status
git add . to stage the new files and freshly edited files
Commit those changes with git commit -m "commit title" -m "description"
Then push them up to GitHub with git push origin main where “main” is the branch name.

All of that was by about the 25 minute mark in the video, and is probably enough for me to go away and get some practice with. The rest covers getting an already established local git repository to GitHub, branching, forking, undoing.