6.5h Tonight was a doozy! Earlier I crushed through a ton of “Learning how to learn” on coursera and it was really interesting. I am more than halfway through, and I need to collect my notes and decide what strategies I want to go after first. They really, really stressed the importance of something like the pomodoro technique. I tried it tonight and I’m less tired and fuzzy than last night. Hopefully this will stand to be true over the long run. I also plan on implementing a quiz making habit as well as reviewing 3-day old and 5 day old notes to do spaced repetition on my lessons.
Later on I did around 2 hours of playing with my mbta transit app. I added a new component that makes a list of stops when given a line. I made it a partially controlled component (more will come later) but right now it receives it’s line as a prop from app.js and I’m happy I was able to get that running.
I also implemented a callback function on the line selector so that it keeps it’s state in app.js as well. I’m looking forward to keeping all of the state together. It feels cleaner that way.
I’m currently stuck with two bugs. I’m not sure how to deal with a promise properly in react (ie without redux) so I am getting unpredictable behavior due to varied response times. The second one seems to be a server error caused by me trying to grab data from two different endpoints. This is a potentially pertinent video from one of the stack overflow answers that I’m going to check out tomorrow. My error has something to do with CORS.
I also did a lot of reading today, so here’s what I was looking at.
This is a good list of ways to make code easier to debug, and methods to make debugging easier. It’s unfortunately written in the negative; it uses “Failing to Read Error Messages” as opposed to “Read Error Messages.” But it still has good info in it.
this tutorial was pretty cool. I’ve been meaning to step up my debug game and this is the key to the next level. They explain all of the different event listeners you can add breakpoints to. Previously I only had a loose Idea of how to add a breakpoint to the code, and no idea about adding them to events.
This clarified a question I have had for a few days now. I’m glad I looked it up. The answer is that an action is simply an object (ALWAYS with a type and usually with a payload), and action creator is a method that outputs an action. There is also something called “action type” which is a specific string used to define and/or group actions together. This is treated very specifically by redux developers and generally is stored in a const and is all caps. They say that the reason for this is to prevent a typo from bringing down the app, but that doesn’t actually make very much sense. The one benefit I do see is that it allows you to change the action type string once and have it ripple through the code easily. Action types are used to route the action through middleware and to the right reducer.
I’ve been meaning to look this up for a while, and I think its synonymous with “use the console in chrome” I know it means Read, Execute, Print, Loop. I thought it was more exotic than this though. I did learn (and actually write down for once) that the chrome dev tools shortcut is command-option-j and to clear the console it is control-L. Those are super useful.
This was referenced in the learning how to learn course so I read it. It had some good, actionable steps. It also mentioned the “cornell notes” style of notebook, which I am going to look up. It seems like a divided page that has space at the bottom for review questions, and a space on the left for keywords and outstanding questions to look up. I like that it is kind of a multitasker, and I’m going to print a few pages up to try it.