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.
One prereq the fired apprentice lacked was a notion of how computer files can be (and should be) organized. As best I figured, she had several hundred files directly on her virtual desktop-- "directly" as opposed to in folders or sub-folders. I'm not sure she knew what folders are. The following becomes relevant: in roughly May of 2019 I became aware, due to a friend, of a bug in Satan's Operating System. If there are too many files (very roughly 400) directly in a folder that you're trying to upload or download to, the browser will lock up / crash when you try to upload or download. That is, if the "open files" dialog encounters too many files, it locks up. My apprentice suffered greatly from this. Her browser kept crashing as she tried to learn JavaScript.
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:
The JavaScript path may get you started immediately. There is little to no overhead in starting. The Linux path involves installing Linux, which may or may not be a big hurdle for some. I outline each below.
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.
So back to source code versus rendered / executed source code: the browser itself is written as quasi-English source code. WikiP says that Firefox is written in "C, C++, JavaScript, Rust, CSS, [and] HTML." In order to run, your browser is executing the source code. Your operating system and hardware are the execution environment for the browser.
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.)
Client-side, web-based JavaScript is a programming language for web pages. HTML tells the browser what to display and how to display it, but HTML is fixed or static or unchanging. The page says what the page says. If you want to display different stuff based on a button or drop down box, that's beyond HTML's capability. That's where JavaScript comes in.
JavaScript allows HTML to "react" to different situations. It allows drag and drop. It "understands" time to a degree and can set timers to show what time it is or how long something takes or to create a nice fade out effect. Generally speaking, it reacts to various input. It makes a web page dynamic.
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.
HTML and JavaScript are intertwined. The first 5 lines are copy and paste boilerplate. I copy and paste it from my own pre-existing web pages. Just take them as gospel for now. LIne 6 is the "title" or what names a browser tab. Lines 7 - 12 are part of the JavaScript. Line 16 has another fragment of JavaScript.
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 have used the term "web-based, client-side" JS without defining it yet. My specific advice is to learn web-based, client-side JavaScript, or JavaScript run by (executed by) a browser. If you just go searching for "JavaScript," one previous apprentice tells me that you're more likely to find Node.js or server-side JavaScript or command line JavaScript or JavaScript run in VSCode or some such.
I recommend you find JavaScript examples that manipulate HTML and thus are run in a browser.
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.
I already have a number of screaming objections to W3School's "My First JavaScript". With that said, it might help. Perhaps I should write out my screaming objections and how I'd do it. From a pro point of view, even I use W3Schools more often than MDN because even I'm usually looking for the simple version.
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.
Even if you don't understand a piece of HTML / JavaScript at all, it should soon be your goal to run it in your browser from a file you created. You should be able to copy and paste examples from the web into an editor (such as Notepad++), save them to your disk as a .html file (such as HelloWorld.html), and then double click or right click, run your file in a browser, and see a result.
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.
My software development rule #1 is "never develop without a debugger." In the context of web-based, client-side JavaScript, "the debugger" is Chrome Developer Tools (CDT), Firefox's equivalent, and perhaps whatever other browsers do. More specifically, a debugger lets you "watch" variables, "step into" code, set "breakpoints," etc. Here is a video on using the debugger. I'd like to think there are examples of MUCH simpler code using a debugger, but I haven't found them yet, and I am not going to look until apprentices have given up.
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.
There are a number of benefits to the JavaScript path. Everything you need to run and debug JavaScript is either on your "real" computer or is free to install. JavaScript is a very real programming language. It is similar enough to the others that it's as good a place to learn as any. You'll need JavaScript if you want to do web development. There is no time wasted along the JS path.
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.
Back to JS, there is a very popular job title of "front end developer." Put simply, that means client-side or front end JavaScript. One option is that you stay on that path forever. You write the front end and I write the back end.
I'd probably live with that, but I would suggest you eventually learn the "full stack"--HTML, CSS, client-side JavaScript, a server language (PHP, Node.js, etc.), a database, and Linux sysadmin.
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.