Back on track
I did a lot of coding and learning today. I attribute my productivity to coffee and my new desk setup. Another thing that helps is to sign out of social media and/or disable notifications.
Among other things, I essentially turned my new mini-ITX hypervisor into a monitor stand. I would’ve needed to put books under it otherwise. It’s a small server and it’s out of the way. I’m completely done with the hypervisor hardware stuff. Now all I need to do is set up some VMs for my current Python project.
Speaking of VMs, I also set up an Ubuntu VM on my desktop. Not on my hypervisor though. Now I can develop on macOS, Windows 10, and Ubuntu Linux. I’ve used all these OSes for years each, but never all at the same time before. They are all really important to be familiar with. But then again, if you use homebrew on a mac to install coreutils, moreutils, and binutils, you get pretty much the same experience on all platforms. On Windows, I have git bash installed, as well as lots of things from MinGW. Most prorgams I use, such as Jetbrains IDEs and VS Code, are multi-platform anyway. And I try to make my software multi-platform too. Java is easy to make portable, and it’s the same with Python.
You can run many different VMs on a single computer as long as you only assign a couple threads to each one. In this case, you can see that some of my cores were at relatively high utilization, while others were mostly idle. This is because my VM doesn’t get to access my desktop’s entire CPU.
Diving deeper into git
Before today, I already knew a few basic git commands. But I’m continuing to learn more with an online class on Udemy. Udemy courses are mostly video tutorials, showing what to do, and you can follow along while they’re explaining it. It reminds me of Youtube tutorials, but with higher standards because there’s money involved. I used to watch Youtube tutorials for things, but many tutorials are outdated or just plain wrong.
Earlier this year, I tried to learn git at a hackathon in St. Louis (where I made this app with someone), but the people who were explaining it to me talked about it in a really confusing way, and then eventually just gave up on trying to teach me and wanted to do it for me, which wasn’t helpful. I even attended a couple CAOS (Computer Association of SIUE) meetings where people went over git, and I was also in an informal Swift/iOS class that briefly went over git. But these meetings, for whatever reasons, weren’t very effective at teaching git.
It can be confusing at first, but this simple $10 course I’m taking is really helping me learn. I think I’ll learn lots of other prorgamming stuff with Udemy in the future. Once you have a formula for how to learn stuff, it gets progressively easier for learning the next thing.
My strategy is to watch the Udemy videos, then to code along with what the person is doing. Learn by doing. If all I did was just watch, it’d go in one ear and out the other.
Of course, I’ve also learn a lot of CS topics in college, though independent learning is a big deal too.
So far, I’ve finished the first 4 sections of this class. I’m trying not to rush it, because if I did all of it in a single day, I’d forget it pretty quickly.
I even made a repo on Github that includes a list of all the git commands I’ve learned thus far. You can check it out here.
Even though I have a halfway decent desktop, I’ve been using my MacBook Air for most things. Lately I’ve been using my desktop more, getting back into using Windows 10 a lot. It’s good practice for doing git push and git pull. Not only that, but you learn about the different between Windows and Unix linebreaks, as well as a lot of other small differences and quirks. For example, my jekyll project worked just fine in macOS, but it gave me errors in Windows. Turns out the autogenerated Gemfile was trying to use a 32-bit version if a dependency when I only have a 64-bit version installed. So I changed a single line in a config file and now everything works again. Tested it on macOs afterwards and it works there too now.
Being a developer means you’ll encounter lots of problems you’ve never dealt with before. Computer science is less about computers and more about problem solving. There’s no developer out there who has memorized every error message and problem. It’s not about rote memorization at all. The difference between a good and bad developer is that a good one has a mental framework for assessing a problem, researching it, and finding potential solutions to apply.
Today, I watched a brief Derek Banas video about Python. It quickly summarizes a lot of things about the language, though it’s no substitute for a real book or course on the subject. Kind of just a refresher going over concepts I learned about in the past. It’s important not only to learn new things, but to review old things in order to keep them in your long-term memory. It’s all too easy to stop using something for a while and then forget about it.
In addition to a video refresher, I’m also enrolled in 2 Python-related self-paced Udemy courses, and also reading an e-book called Python Crash Course. This isn’t the first book I’ve read about Python. In the past, I read Python Programming for Beginners, but it was really too basic to be useful. I hope this one won’t be like that.
I am commiting semi-useless learning scripts to my misc python learning repository on GitHub to showcase what I’m doing. A lot of it is really basic so far, but I’ll get there eventually, especially when I get comfortable enough with the language to start a Udemy course about Python and Qt, which isn’t aimed at beginners. I’m currently at an awkward phase of Python proficiency where I know too much for complete beginner resources to be helpful, but don’t know enough to really understand advanced material. But it shouldn’t be like this for too much longer.
The importance of mockups and planning
My last app was an encryption/decryption tool called EZcrypt, which aimed to make encryption easier. Before making the program, I used Keynote on my MacBook to make this ugly-yet-functional mockup:
And here’s what the program ended up looking like when I finished it:
The mockup, as well as notes I wrote down, helped to guide the project. It wasn’t anywhere near as formal as something like UML, even though I’m familiar with UML. But I wanted something quick and visual, especially since I’m trying to do more GUI programs instead of command line stuff these days. These kinds of preparations are really useful and make the development process easier.
I’m going to do the same thing for my static site generator.
Here’s a very basic beginning. It’s not great, nor is it finished. but it’s the first mockup for the first (of many) screens. This mockup was made with LibreOffice Impress as opposed to Keynote, so it looks worse, and it’s clunkier to use too. But I’m trying to use Windows more instead of mostly just using macOS.