You need a laptop or desktop. In part to show my middle-aged crankiness, I'll call these "real" computers. This issue is not only about my prejudice, though. Neil Postman and others warned us decades ago of the dangers inherent in the television medium. "Real" computers show(ed) the potential to be a devastating counter-attack for Good over Evil, relatively to television. With mobile devices, I fear society is heading back towards the evils of television if not worse. (I need to write an essay on this one day.)
Not only do you need a "real" computer, but you probably should read this using one. Along the lines of the larger issues mentioned above, a mobile device is not a substitute for a real computer. Yes, mobile devices are very useful, but they are not substitutes. Also, you should probably write me from real computers. I am not of the generation that wants quick communication over detailed communication. Similarly, it helps if you type fast at a "real" keyboard, or you start learning to do so.
As a reminder to myself and a warning to both of us, I usually am not in a hurry to talk to you by voice. Writing software is *writing* software. If you can't write in a human language (English for my purposes), you may not be able to write to a computer.
I once made the mistake of getting on the phone too quickly with an apprentice. This wound up wasting both of our time. That is the only apprentice I ever fired. I need to be sure you pass my writing tests. I am not a snob against SMS-speak. I don't care so much about spelling or grammar or abbreviations or whatnot. If I can figure out what you mean, it's good enough. I should mention, though, that computers do care about spelling and grammar. They have no flexibility in the matter.
I'm not going to avoid gender pronouns. The fired apprentice was female. I've had great female apprentices, though. I'm in touch with one of them 7 years later.
It's one thing if your virtual desktop is a mess. It's a problem, though, when you have no idea how to fix the problem.
Along similar lines, it is a good sign if you are aware of the existence of file extensions (.html, .htm, .js, .doc, .docx, .pdf, .exe) and how to "turn them on" / see them in Satan's Operating System. It's hard to run an HTML file if you can't save it as MyFile.html
I envision two possible paths for my software apprentices to begin:
All software is written as quasi-English "source code" (at least for our purposes). This document is written in HTML. Otherwise put, HTML is the source code for a web page. HTML is Hyper-Text Markup Language. It is a software language whose purpose is to "mark up" or describe the structure of a human-readable document. What you see on the browser screen is not the source code. You're seeing the rendered or "executed" page. The page is rendered or executed by your browser. A browser is the "execution environment" for HTML.
You can see the source code of this page or any other page by pressing Control-U (on a real computer). It may be Command-U or some such in the iCultOS(X). Control-U works in Firefox (FF), Chrome, and Brave. More generally, you're looking for "view source code" or "view source" or "view page source." Anything on my site is hand-written and thus should be more-or-less readable. Various sites vary widely in how readable their HTML is. Facebook tends to scare me, too, although I've puzzled it out in great detail before.
Regarding terminology: writing software, programming, developing software, or dev'ing mean the same thing.
Back to HTML, as it says on the label, HTML is a markup language. It's about the structure of a human-readable document. It is a software language, but it is not a programming language. I will very roughly define a programming language as a language that directs a computer to do different things based on different information--"read" input, make "decisions" based on that input, and output something based on those "decisions." Programming languages handle a wide variety of inputs (keyboard, mouse, files, network, camera, etc.), make very complex decisions--if this do that, eventually with 100s of "ifs"--and then output the result. (CSS (to be defined later) does very rudimentary "decision making" based on very limited inputs, but it's not remotely powerful enough to be a programming langauge.)
Here is the next lesson--the blue screen button.
Hopefully you will guess that, after pressing the button, your assignment is to hit control-U and look at the source code. For purposes of feedback, the current version is 20 lines long or 21 with a blank line at the end. Both Chrome and Firefox number the lines in their source viewer.
It's not yet my mission to explain everything. But that's about as simple as it gets. I would hope you can look at that and look things up and start to get an idea of how it works.
There are other short lessons in the directory (folder) that contains that lesson.
In answer to the question of whether I can recommend videos, websites, etc., the answer at the moment is yes and no. It's my job to point you in the right direction, answer questions about that direction, and then try to re-point you accordingly. Similarly, it's my job to explain what you're doing wrong when you're head banging after a given period. I am not being paid enough to create a course. It's very, very hard work to create a course. So I will tell you what to look for. Your job is to grub around and spend at least a few minutes with a number of sources. If you're no better off than when you started, that's fine. Let me know. As with "head banging," otherwise put, one of my jobs is to try to reduce your frustration.
Back in 1992 it might have taken me 3 hours to solve a syntax error. To a limited degree that taught me how to debug, but I don't think that level of frustration was worth it. It would have been nice to have someone point me to the bug. Given that I wished I had someone then, my job is to point you to the bug or at least help you to solve it in 20 interactive minutes rather than 3 hours of flailing.
For the record, I still make syntax errors every 3 - 10 minutes when dev'ing, but I usually solve them in 5 - 20 seconds. Occasionally I still get flummoxed, but that's usually because I'm violating my own rule of dev #2, which is another issue for much later. Rule #1 will be addressed soon.
As for learning JS, otherwise put, you tell me what's out there, and I'll help you evaluate it.
With that said, I have some advice.
I'm told that the Mozilla (Firefox) Developer Network's material (MDN) is in some ways very good but is badly organized.
From a professional point of view, MDN is the definitive reference. I use it often.
As with any source code, it can be written in a simple text editor. If you must use Satan's Operating System, you could use Notepad. From years ago, I recommend Notepad++. VSCode may be fine, but just don't execute non-HTML-related code in it, at least not to start. With that said, I've never used VSCode.
Whether it's Notepad++ or the equivalent, you want something that colors the code and preferably shows you syntax errors and such. To answer an interesting question from one apprentice, the color is not inherent or necessary. It's just a visual aid, a feature of the editor. The color is not part of the source code. Different editors will "decorate" / color differently. Your source code remains unchanged.
Then make any minor change and refresh the page, and make sure you see the change.
Just getting to that point is progress. That was more than the fired apprentice could achieve fluidly.
I'm not sure how much good that video does at the very start. But I suspect something similar is out there.
In May, 2020, I was finding it harder than I hoped to find debugging examples. I found a few that may help, though.
It may take weeks, but you'll eventually hit a limit to what you can do in client-side JS. You can do anything to a web page, but, for example, you can't (reasonably) save the data without a server.
My medium-term goal with an apprentice is that you can start to understand my code. I generally write in PHP (server-side), MongoDB, and the Apache web server in Linux. I'm typing on Ubuntu Linux 18.04 (LTS) desktop. Kwynn.com runs on Ubuntu 20.04 (LTS) server.
I had one apprentice who didn't seem to know at any level what an operating system is. I'm not going to go deep on the subject, but a few words are in order. Some relevant OSs are
The VM (virtual machine) sub-path means getting Linux to work inside another operating system. Two or three apprentices have gotten Ubuntu Linux working in Oracle VirtualBox in SOS.
I've played with VirtualBox within Linux--virtualizing one Linux VM within Linux. I've always had trouble getting it working, but my guess is that VirtualBox actually works better in SOS. Whatever OS, you download the Ubuntu Linux 20.04 desktop ISO, download VirtualBox, and the install / run the ISO within VirtualBox.
The native install probably isn't any harder. You can set up your computer to dual boot. That is, you don't have to erase SOS. Linux will install itself such that you chose which OS you want at bootup. You download the ISO just like above. Mine is called "ubuntu-20.04-desktop-amd64.iso" Pretty much everything is 64 bits these days, and "AMD64" means both AMD and Intel. You'll need a USB drive that you can erase, or a DVD if you're old-fashioned. A 4 GB USB drive will do. Then, in SOS, you download Rufus, which creates a Linux installer from the ISO.
It may be as simple as creating the installer USB as above, booting your computer, figuring out which button allows you to change the boot device, then booting off the USB. The installer will ask if you want to install Linux "alongside" SOS. It may be as easy as saying "yes" and letting it do its thing.
I don't know by default how much space Linux will take for itself. If you're doing it manually, you might get away with 25 GB for Linux. Every bit more is better. 40 GB should last you a while. I ran with 80 GB for 1.5 years.
Full install instructions are on Ubuntu's site.
I often have a problem with "page clouds" (webs) getting spread out, so here is an attempt at unification.
(July, 2020) Make it clear that you can write client-side JS on your machine and execute it. As of September 14, 2020, this should be clearer.
The backlink back to one of my previous iterations.