Category: Tutorials & Practice

  • What I’m Learning from Learning French

    So there are people way more equipped than me to talk about How To Support Learning. But following up on my post from a couple weeks ago about what makes self-directed online learning difficult, I wanted to think about how to ease some of the issues I was talking about.

    The two things that came to mind are defining the why and finding community.

    I know I can’t shut up about Duolingo, but it’s the thing I’ve had the most success with, so I’m gonna keep chattering about it. I mentioned in my last post that I was getting frustrated with Italian, feeling kind of stagnant — my grammar wasn’t great and neither was my vocabulary. There weren’t exercises available to me for composition/writing/speaking, only for comprehension/reading/listening.

    So in the past two weeks or so, I’ve switched to French.

    And it’s really working! I’m doing more lessons in a day, making noticeable progress through the Rookie section of the course (the overall course is more than two hundred units, yeesh — I’ve finished about 2.5). I’m not in anything advanced yet, starting from total basics, but I’m feeling more motivated than I have in a while.

    Why?

    Well, the first part is probably just plain old novelty. Switching things up reinvigorates me, and I can get excited about something new because it’s easy to feel like I’m making progress when I’m still in the beginner phases, before I reach the frustration plateau of “not complex enough to feel like I’m really achieving anything but still complex enough that I don’t really get it”.

    But parts two and three — the why and the who — are the reason I picked French, and the reason I’m excited. And they’re sort of the same reason.

    I didn’t actually pick up Italian to talk to people. Of the few people I know who understand Italian, there’s not really anyone in my life who I would regularly use it with, either because they’re not particularly practiced either or because I see them very infrequently. So I didn’t pick up Italian because of community, but because a character I was playing in my Shadowrun TTRPG speaks Italian, and I thought it would be neat to try. Which isn’t the worst reason in the world, but it wasn’t as if I was going to use Italian in the game, just that I was going to learn it in addition for fun. No further purpose.

    But unlike Italian, I have several friends whom I talk to regularly and who also speak fluent French. I can speak French around the house, and get feedback on my pronunciation and grammar. Like I said, I’m still in the little leagues, so my vocabulary is limited, but “Are you eating? I’m eating with you,” and “Look! A dog!” feel like they’re pretty applicable to everyday life nonetheless.

    Having a community of people who you can use your skills with, to have fun with them and get excited about stuff, to learn from and to learn with, is a huge boon to learning. Understanding your own goals helps you stay motivated and remember why you’re doing it. And if those two things can overlap, so much the better. In any case–

    Au revoir, arrivederci, and see you next time.

  • Learning to Learn; or, Online Barriers for Total Beginners

    Coming off of Reclaim Open, one of the things I’m thinking about is online resources for self-teaching beginners. When we were interviewing people for the documentary, we asked people what they were glad the internet had now, in the present, that it hadn’t had in the past. And a lot of people — not everyone, but a lot — talked about how there’s a plethora of learning resources for beginners on just about any subject. Which got me thinking about the learning resources that I’ve used and the tutorials I’ve tried to follow.

    There are so many things that I want to learn. I’ve got a post in the works about teaching myself to draw. About a month ago, I hit a milestone on my Duolingo streak (800 days!). I used to practice guitar, though I’ve fallen out of that habit in the past year. For a while I was experimenting with some of the beginner guides to Unity. I have an abundance of tutorials and resources on various topics bookmarked — a beginner’s guide to Ruby on Rails, Codecademy, HackerRank, etc. — which I’ve used… at some point in the past. I keep a list of topics to research that only gets longer and longer.

    All this, and I still feel like a dabbler in everything. Part of it is that I’ve put aside topics for long periods of time (almost everything except Duolingo, honestly). That’s naturally led to skill atrophy and forgetting what I was doing, which means difficulty picking up where I left off. But for the one thing I have stuck with, I don’t feel like I’m getting any better — my Italian is beginner-level at best, with a poor grasp of grammar and difficulty remembering vocabulary when I need it.

    So I’m thinking: what are the differences in the resources I’ve looked at? What do they require? Where do they go together, and where do they fall short?

    The framework I’ve got in my head right now for self-teaching is structured vs unstructured learning resources.

    Structured resources are things like Duolingo or Codecademy, a series of tutorials designed to build on each other. Unstructured resources are more like the Youtube video tutorials that exist for drawing or guitar, and their related practice tools (guitar tab websites, figure drawing photo banks).

    Structured resources are designed methodically by one group in a way that emphasizes logical progress from point A to point B to point C. There’s a general focus on fundamentals first, then building up to more advanced concepts, with exercises designed to practice each new topic. The exercises are usually short and easy enough that lessons can be completed in 5-10 minutes max, to encourage making learning a routine and habitual practice. The focus is on progressing through the course.

    Unstructured resources means that there’s a wide range of sources from various unconnected groups, which all specialize in different topics. Learning is self-directed, since there’s no clear path connecting everything, and there are few if any pre-built exercises (a given resource might have 2 or 3, but none of them hang together). Learners can focus their studying in their weakest areas, or specialize in the topics that most interest them, and the lack of pre-built exercises means that their learning goals shape what they’re working on — which means that there’s more intrinsic motivation to learn, since they’re tailoring their practice to their own interests. The most common advice I hear for people who want to learn guitar is “Pick a song you like, and learn to play it.” There’s simplified versions of just about every song out there so beginners can learn the most basic version, and once they have that, they can try something more advanced. It’s learning by doing.

    With structured learning, there’s issues of pacing, attention span and motivation. Short, easy lessons are designed to keep attention and build routine, so you can do a little bit every day, but if you do only a little bit every day it might feel like you’re taking months or years to get anywhere. That damages motivation, which is doubly bad because you’re working towards proficiency but not a specific intrinsic goal; that makes it extra-hard to measure progress.

    Curated and designed exercises may also not be right for all learners, or self-structured online learning may create certain pitfalls. For example, one major issue I have with Duolingo is that because of the way its lessons are structured, there’s no way to have exercises strengthening true composition (written or spoken). There’s options for translating back and forth between your native language and your target language, but there’s nothing along the lines of “Write a paragraph about your favorite book” or “Talk about your most recent vacation”. That’s a major barrier to fluency, since being able to read and listen in your target language is only one half of communication, and it’s the less challenging half.

    With unstructured learning, though, you still get pacing, attention span and motivation issues. This time the issue is that it’s hard to know how much time to spend on certain topics, and where to start or how to build on them. Dumping time into something while feeling like you’re stumbling in the dark trying to figure out what you need to do next is a sure way to damage motivation, which can in turn make your attention focus elsewhere.

    Exercises for unstructured learning can also feel repetitive, since your resources only give you a few. Everyone says the way to get good at drawing is to practice figure drawing, which is true — I have definitely improved as a result — but I don’t know how to vary it up to keep learning fresh or which details to pay attention to in order to practice most effectively. And if it’s not repetitive, it’s chaotic — everyone has an opinion, and everyone disagrees. Who do you listen to, and how do you cut through the noise and really decide how to spend your time?

    This is a long way of saying: I’ve never learned to teach, and I don’t know how to learn to learn. Because self-structured learning is way different than learning in a classroom, or in a group, or with a mentor. There’s no external framework to keep you accountable, or to provide feedback, or to provide any of the other benefits that come with a learning community.

    When it comes to self-directed learning, there’s so many principles I keep hearing about — resilience, goal-setting, failing forward, varying your practice, etc. — but all the resources I’ve found assume learners are coming to them with those principles already well-developed, and that all that’s left is the skill-building section.

    Which makes sense! Teaching your learners how to self-teach before teaching them what they actually came to learn, is an absurd thing to ask. But for pretty much everything I learned in school, I learned from other people; I almost never got practice teaching myself.

    So there’s a lot of beginner-friendly resources out there. And they’re great for if you have one or two specific things you need to learn. But for people starting in total ignorance who want to work their way up to overarching mastery, how beginner-friendly are they really?

  • So I Had Some Commitment Issues…

    Revisiting Git & GitHub

    So as luck would have it, a couple of things have dovetailed in my work recently. In my last blog post, I talked about the experiments I’ve been doing with HTML & CSS, building site files directly instead of using WordPress or another application. Ideally I’d like to learn more about JavaScript and PHP as well, so thinking about how HTML, CSS, JS and PHP files slot together is part of that. I also had to roll out my HTML/CSS site, my Hideous Creation (that’s its name now, I’m not taking it back) by manually uploading it to cPanel.

    This month I’m also working on revising our GitHub related documentation for this month. There’s only two articles, one on how to point custom domains and subdomains to your GitHub Pages site and one on how to… well, set up a GitHub Pages site (using the GitHub desktop app & Jekyll). My revisions are primarily centered around making the language more cohesive, double-checking that all our links work and our screenshots are accurate, and confirming that the process we’ve outlined is still up-to-date. That means that the best way to do it is to work through them myself.

    Maybe you’ve started to see where this is going.

    I didn’t have GitHub configured on my computer yet — I set up an account a couple months ago when I started working through some PHP tutorials, but never had any files that I actually would consider sharing. I was honestly a little nervous! It’s been a long time since I used Git, particularly from the command line, and I didn’t want to install the desktop app, since a) it wasn’t how I originally learned to use Git and b) it felt tantamount to giving up.

    Of course, to work through our documentation and update our screenshots properly, I am going to have to install the desktop app eventually, but I’ll live (and maybe, if I’m ambitious, I’ll add a new section that also walks you through using the command line). I’ve found resources that have helped me review and practice Git commands. And with the Hideous Creation semi-realized, I have something to put out into the world!

    So, what does that mean? No more excuses.

    The Tech Part

    GitHub does try and make it easy for you to start a new repository, right from the homepage. Maybe it’s just because I haven’t done a lot of work with my account, or my homepage is still set to the default configuration, but right at the front and a little left of center is a quick-start area for a new repo.

    GitHub’s “Start a new repository” feature, making my life easier.

    And after that, they provide instructions! They have a quick-setup option for people who’ve done this before, and then for those who haven’t, there are instructions on how to create a new repository or push a local repository to GitHub. Great!

    You’ll note that these are very informative, as long as you’ve already logged into GitHub through the command line.

    Except… GitHub does assume that you’ve already connected to your GitHub account on your computer. So these are the steps you’d take after you’re logged in… which I wasn’t. And I couldn’t remember how to. Oops.

    So when in doubt, tutorial time.

    I found a tutorial by Karl Broman titled “git/github guide: a minimal tutorial” which did start me at the very beginning (a very good place to start). Without going into tons of detail, the important bits were getting my GitHub account connected (with SSH) and starting/pushing my repository. Technically speaking, what I set up wasn’t a repository for Hideous Creation — it was a repo for “Hideous Creation – Git Experiment”, which was a duplicate directory for the original HC, because I didn’t want to use the directory where I was actually doing my work as the place where I was also doing all my Git experiments. (This was probably a smart idea, but it wasn’t a smart idea I had before I started working. This was a smart idea I had about four steps into the process, which meant I had to go back and start over.)

    Everything was working mostly really well until I tried to set up a .gitignore file and found that the directions in the tutorial were just straightup wrong — it implied that git add .gitignore would create the file, but add doesn’t create new things, it yoinks an existing thing and adds it to the list of things that’ll be committed to the repository. So instead it just threw errors because the command was trying to look for a file that didn’t exist. A bit of googling later, and GitHub’s own documentation informed me that the command I wanted was touch .gitignore. So, checked off that step.

    And then I hit a weird patch.

    • I got all my files added (git add filename1 filename2 filename3 filename4 filename5…, etc.)
    • checked that they were ready to go (git status)
    • got connected to the repository I’d already made on GitHub (a little late in the game, but no big deal), which based on the tutorial was git remote add origin git@github.com:username/new_repo, but here was git remote add origin git@github:CapnPilot/hideouscreation-gitexperiment [Note: this is how you connect to the repo through SSH, GitHub’s instructions in the screenshot above are oriented towards connecting with HTTPS]
    • created a commit (git commit -m "My first commit")
    • and tried to push that to the repo (git push -u origin master)

    Which didn’t work.

    In fact, I tried a couple times. None of my commits were getting pushed.

    Note: I didn’t get any errors, so nothing was wrong with the syntax of my commands (that I knew of), but when I went to GitHub and looked at my repo to check my work, there was nothing there. Nothing had been pushed. Which was a little weird.

    After a whole bunch of puttering around and cross-checking things, I noticed that in GitHub’s original instructions, which were oriented towards connecting your repo using HTTPS, the formatting was always git remote add origin https://github.com/CapnPilot/hideouscreation-gitexperiment.git, with that little .git extension on the end being what particularly caught my eye. That extension wasn’t included in the tutorial, but it seems pretty likely that the author thought it would be well-understood.

    But I missed it, and in doing so I’d connected my local directory to a GitHub repository that didn’t exist using the wrong remote URL. What I needed to do now was to replace my old work, making sure to keep using SSH instead of HTTPS despite GitHub’s original instructions.

    I was worried I’d have to fully remove the incorrect remote URL and replace it, and that removing it would break something, but nope. Turns out you can just switch remote URLs! That was actually something I found in GitHub’s documentation, under “Managing remote repositories: Switching remote URLs from HTTPS to SSH.” And you don’t actually have to be switching from HTTPS to SSH to make this work. You can be switching from an incorrectly configured SSH remote URL to a correct one, and it’ll still be A-OK.

    The ending is a bit anticlimactic to describe: I re-added my files, re-committed them, re-pushed the commit, and it worked. But after the stress and irritation of figuring out what I’d done wrong and whether it was fixable, it felt really cool to refresh the page and finally see my work come through.

    I’ve written a pretty epic saga in order to describe what’s essentially, “I set something up, broke it immediately during setup, and then fixed it,” but I’m pleased. It’s fun to putter around and try stuff and experiment. I like being able to pull different areas of my work together into one cohesive whole. Working with Git again feels one part familiarity, one part learning, which is always a good zone to be in. And I still haven’t actually gotten to start on the GitHub Pages parts, so there’s more to do yet.

  • Containers Workshop Week 1: Hello, World!

    Just using this space quickly to type up some thoughts about Week 1 of the containers workshop we hosted in July. For a variety of reasons I’m only now getting the opportunity to work through the exercises, one week at a time, so here we go.

    Week 1 covered an introduction to containers: what they are, why they’re useful, where the idea comes from, and how to get started. Jim likened digital containers, which I often reductively describe as “scalable micro-servers”, to real-life shipping containers: a way to package a specific thing or set of things (in this case, softwares) in a way that keeps them isolated and secure, that standardizes how things are organized, that keeps them flexible and easy to rearrange, and that reduces the cost of (in real life) shipping or (on the web) hosting.

    Getting started meant going through the Reclaim Cloud interface, which I was already somewhat familiar with. We covered how to locate the Settings area, how to set up a new container using the marketplace, where that container and its nodes (component sub-containers) live, and how to access the settings, configuration, and terminal for a given node.

    The exercise for the week was to set up a Docker container using the marketplace’s installer and then use the terminal to run the command docker run hello-world. The tutorial video also showed how to poke around inside the environment topology, how to find a given container’s settings and file manager, how to create new files and folders, and several other things.

    This was a good combination refresher-intro — it helped me refamiliarize myself with tools I’d already used and understand a little more about how they work and what they’re made up of. It was also useful from a terminology standpoint, as that’s often where I’ve had issues in the past — while I can conceptualize things, understanding what a person or a tutorial is referring to with a given term can be really difficult for me.

    Questions and Takeaways:

    • I was still pretty unclear on what actually happened when I ran the docker run hello-world command. Something definitely ran, because the terminal printed out some introductory information, but when I navigated to the URL for my environment, I got an error that nothing was there.
    • While the container can just run the command and stop, it’s still active in the background and using resources — so what’s it using them for, if it isn’t doing anything?
    • How would I set up/program an environment to continue running indefinitely? I know it’s possible because that’s how Reclaim Cloud applications run, but I don’t know what I would need to do if I wanted to develop my own little application.
    • For that matter, how would I build custom Docker images for those little applications?
    • I need to review setting up SSH keys so that I can choose between the Reclaim Cloud terminal and my local terminal if I want.
  • Docker for Beginners: Hello, World!

    Today I got started exploring Docker for the first time, using A Docker Tutorial for Beginners. Reclaim Cloud runs using Docker containers, and a few of us will be doing some research on it in the next month or so, so it seemed like a good thing to try.

    Docker is, as I understand it, a system for running containers, which are a less resource-intensive alternative to virtual machines. You can spin up a container using a particular system, run it while you’re using it and pause it while you’re not, and interact with it through the command line.

    I spent most of today messing around with the Docker Desktop interface, which I found extremely frustrating — the tutorial itself was lovely, but… essentially, I understand that documentation is usually aimed at the lowest common denominator, but today I wish they had aimed a bit lower. Specifically, nearly all of the features that the documentation offered instructed you to click on a button shaped like a tiny whale, which would open a pulldown menu of options that you could then choose from. It took me forty-five minutes and another person’s help to find the tiny whale, which turned out to have been placed not anywhere in the actual window of Docker Desktop, but in my menu bar at the very top of the page, where it could blend in neatly with my clock, my battery and my Wi-Fi indicator.

    Today I worked up through the Hello, World! section of the tutorial, which got me through both how to set up Docker & Docker Desktop, and what some of the basic concepts and tools of Docker are. To the best of my understanding, Images are a bit like modules or applications – they tell Docker what any container modeled on that image will be capable of doing. Meanwhile, Containers are individual instances in which to run your programs.

  • JavaScript with LinkedIn Learning, Day 4

    Just a short post today. I’ve been following up on the practice exercises from last time, building a class and using it to create objects. I ran into some issues with it, though — I can’t access my new class and its constructor from the browser console.

    My first suspicion is that it’s because I switched browsers (formerly using the Firefox console, now using Chrome). Maybe Firefox is more forgiving in some way — but I can’t think of why this would be. Might be some way in how I imported my code into the HTML doc, but I’d be very surprised about that. I checked the template to see whether I was missing something and saw a statement of export default [ClassName], so I added that to my new class, but it didn’t make a difference.

    I went into an older example of script.js from one of the non-practice lessons, which showed how to import classes, and made sure I’d set everything up right (having different JS modules imported in the right order, etc.), but still couldn’t make it work.

    That’s all for today, but I think next steps will be to go through the ES6 import syntax and see if there’s anything else I can do to fix this.

  • JavaScript with LinkedIn Learning, Day 3

    Another day, another example of JavaScript doing things strangely, where strange is defined in the self-centered manner of “not how I would expect, based on what I learned”. This time it’s the flexible method of creating a class: either using a declaration:

    class ClassName { properties }

    Or using an expression:

    const ClassName = class { properties }

    According to the lesson the trend is towards using an expression, but the instructor uses a declaration, and it seems to me to line up with other languages’ way of doing things a bit better.

    You can also create a “class” of objects just by creating a constructor function, which will contain all the properties including other functions (in the declaration and expression options, the constructor function is separated out from the other methods of the “class”), like so:

    function ClassName ( attributes ) { properties }

    Here attributes are the variables passed into the constructor and properties are any work done to set the instance variables, any other variables, and any other functions the “class” might have.

    The tutorial makes a point of saying that creating a “class” by just using the object constructor function is not the same as making a real class, and that real classes are much more flexible and extendable than just using a function, so the third option is not recommended; it’s just that JavaScript didn’t have classes for a while, so older code and tutorials might use object constructor functions.

    That’s going to be all for today — hoping I get some time to put this into practice soon.

  • JavaScript with LinkedIn Learning, Day 2

    Bracket Notation

    The first big thing today was learning about accessing the properties of different objects. The standard notation – aka, what I’m used to – is dot notation (object.property), but today I discovered bracket notation, which looks like object["property"]. This is used for cases where the property is a variable rather than a constant, or the property might not conform to JavaScript naming conventions (basically, there’s nothing preventing an object or variable from being named in a way that breaks the rules, so the code will only break at runtime, and even though you would never write such messy code, you might end up using data that wasn’t meant for JavaScript). It’s a safety valve.

    Object Practice

    It looks like I actually worked a little bit ahead last time when I decided to design my own soup objects. There’s actually a built-in stopping point in the tutorial where you’re encouraged to pause and put into practice what’s just been covered. I ended up having to go back a little bit to last week’s exercises, as over the weekend my memory of the syntax got foggy, but I ended up building a JavaScript “earring box” object (the tutorial encouraged making a container object, so that you could have smaller objects inside your object).

    const box = {
      name: "Earring Box",
      material: "velvet",
      color: "black",
      pairs: 1,
      earrings: {
        material: "gold",
        style: "dangly",
        length: 1,
        gems: "rubies",
      },
    };
    
    console.log(
      "My earrings are",
      box.earrings.material,
      "and I keep them in a",
      box.color,
      box.material,
      "box."
    );

    And a quick screenshot to fix those readability issues:

    So far, so good. I’m sure I’m not breaking any new ground when I say that, for all that it’s based on Java, JavaScript has some major stylistic differences that are tripping me up. Most primarily the way it’s having me declare variables, though I’m currently willing to suspend judgement as the tutorial acknowledges that it’s doing things a little bit out of order for the sake of learning.

    Functions

    The next step, after making an object and giving it properties, was to work ahead on functions. This bit was also something I skipped ahead on last week, as knowing how objects and methods work means that I could recognize the patterns early. Interesting to me, though, was that in the same way that JavaScript has an alternative to dot notation, it also has an alternative syntax for declaring functions (and one which the instructor said was considered more common and better practice).

    The difference is between method(arguments), what I would consider the conventional way of doing things, and method: function (arguments), where the method is listed as a property of the overall object in the same way that other variables and constants might be. In my example code, box might have openBox: function (lidUp) as a property alongside name and material.

    Making My Own Functions

    The function practice exercise didn’t involve adding functions to the object I designed (though I might go back and do that anyway); it gave a template backpack object and asked us to create functions to change the properties the backpack already had, and describe those changes. I also ended up creating an extra method called introduceMe() in order to save a little time on the sentence describing the changes:

    introduceMe: function () {
        console.log(
          `This ${this.color} backpack is named ${this.name}. It has ${this.pocketNum} pockets and holds ${this.volume} liters.`
        );
      }

    In doing so I figured out how to insert variable names into strings, which will save tons of time in the future.

    End-of-day reflections: this tutorial isn’t doing a lot to teach me new principles of coding, but it is getting me more familiar with JavaScript syntax and getting me back into the rhythm of writing code, which is honestly all that I’d hoped for from it.

  • JavaScript with LinkedIn Learning, Day 1(ish)

    As per usual, the “first” day was all setup, and the real day one is where the learning starts. I’m following along with this tutorial in LinkedIn Learning, to get familiar with some of the basics of JavaScript.

    Fun Little Tidbits

    Special Commenting Trick: First, I learned that you can put your cursor on a line of code (or highlight multiple lines) hit CTRL+/ in order to comment out those line(s). Probably old news for some people, but absolutely magic to me, I’m a very big fan.

    Special Editing Packages: Part of the tutorial was also installing ESLint and Prettier, two packages that will automatically check for syntax and formatting errors and either call your attention to them or clean them up (so, ESLint will flag errors, and Prettier will enforce rules about semicolons and spacing in order to make your code more human-readable).

    Now I Know

    Order of Operations

    JavaScript works in concert with HTML and CSS. If HTML is the skeleton and the muscles, and CSS is the skin, JavaScript is the brain and the nerves that can make it all move (I made this metaphor up myself, so if it’s inaccurate or just plain gross, that one’s on me). In an HTML document, it might look like this:

    <script src="script.js"></script>

    It’ll be located somewhere in the <head> section of the HTML document, alongside the CSS source and other metadata information, for purposes of well-organized code.

    If your HTML script tag written like this, then as the page loads, the browser will read through the document, hit the script section, and start working through whatever’s in script.js. Which is great, unless script.js needs to act on code that hasn’t loaded yet.

    Okay, so we put script.js at the end, outside <head>, in the <body>. But no, wait — that’s bad for code organization, and what if we want script.js to be referenced by stuff that needs to load after it?

    <script src="script.js" async></script>

    The way to fix this is the HTML terms defer and async. async means that, rather than running the document, hitting JavaScript, loading the whole script, then running the whole script, it’ll run the document, hit JavaScript, and then load the script while continuing to run the document/load the page; once it’s done loading the script, it’ll stop loading the page, run the JavaScript, and then go back to loading the page; defer is similar, but it saves running the script until the entire page is loaded. This way you can have the code organized neatly and run at the right times.

    The difference between the two is in part down to render time (or, how long it takes for the page to fully load). Without async, the page stops loading in order to both load and run the JavaScript, seriously impacting render time; async impacts render time slightly by loading the script in parallel with the page, then stopping momentarily to run the Javascript before continuing with the page; and defer doesn’t impact render time (because it doesn’t run until the page is all loaded) but does make you wait on your JavaScript.

    What I Made

    After messing around with the tutorial on how to create objects and declare their properties and methods, I decided to mess around a little in the console and create my own. What I learned is that if you create a constant object, run the code to see if it works, clear the console, add in some more properties and functions, and then re-run the code to see if it works, that doesn’t necessarily actually get rid of the original object, and you will get error messages telling you that you can’t re-create the object, because it already exists as a constant.

    I ended up just renaming the object, because it was simpler.

    Anyway, if you want to try my code, here you go! See if you can guess what it does before running it.

    const beefSoup = {
      broth: "beef",
      numPotatoes: 6,
      noodles: true,
      strain: function () {
        this.numPotatoes = 0;
        this.noodles = false; },
      tellMeAboutIt: function () {    console.log(this.broth, this.numPotatoes, this.noodles); }
    }
    
    beefSoup.tellMeAboutIt();
    beefSoup.strain();
    beefSoup.tellMeAboutIt();

    The formatting’s a little funky because WordPress doesn’t respect line breaks, so here’s a screencap of it as well.

  • Rails Girls, Day 3

    Been a while, hasn’t it? Anyway, I’ve finally had a bit of time now to sit down and revisit the tutorial.

    The next steps in the tutorial (the link is here if you’re interested) are regarding adding picture/file uploads to the server (so, section 4). This bit started off pretty simple. I did hit that one error they warn you about, where the uploader cannot be found and you need to add another gem, but that only added a step that was basically identical to the one before it, so it was fine.

    The only major snag I hit was in the step which has you add the code showing the picture (rather than just its filepath).

    They ask you to change

    <%= idea.picture %>

    to

    <%= image_tag idea.picture_url, width: '100%' if idea.picture.present? %>

    Which for some reason generated astronomical amounts of errors. The reason is probably that I did a lot of things wrong. The first error was caused by referring to a local variable as an instance variable (Ruby differentiates these by starting instance variables with an @), but I tried to fix that by using some of the formatting from a different edit RailsGirls had me make, assuming that they had just messed up their second instruction.

    <%= image_tag(@idea.picture_url, width: 600) if @idea.picture.present? %>

    Doing this did not actually fix the problem. It made it worse.

    I decided to debug by adding this as an extra list item, rather than replacing a list item already present, so that I could narrow down where the issue might be coming from. Naturally, I messed up the HTML tags immediately and caused a new issue.

    But! I found that problem almost right away, got that cleared up, double checked why/how the parentheses might be working or not working, realized that the @ symbol shouldn’t be there, removed that and the parentheses, and everything started working again.

    Verdict: I need to review Ruby syntax.

    The static pages and routes finetuning were very easy, and I didn’t run into any issues there, which means that I finished that section of the tutorial today! The next section is about pushing your work to GitHub, but I don’t think I’ll do that right away; I want to do a bit of monkeying around with HTML, CSS and Javascript before I push anything.

    Onward!

css.php