Use this gist to write down notes and questions as you read through the lesson plan. https://github.com/turingschool/lesson_plans/blob/master/ruby_04-apis_and_scalability/react_in_theory.markdown
It's used to create user interfaces. Small components that present data. Tells HTML what to render and how to respond to events. (?Well structured component tree?) Clarify how different from regular JS and JQuery? Unclear.
Each component has a render function. It executes the code and renders the JS and HTML in the return statement. ?Virtual DOM? React listens for state changes (data that can change) and re-renders it (in contrast to polling the data). When setState is called in a component, React knows to re-render it. (?Clarify mounted on the DOM?)
function countdown(n) { | |
if (n < 0) { return n }; | |
console.log(n); | |
countdown(n-1); | |
} | |
countdown(4); |
Step One: Watch Mary Rose Cook Live Codes Space Invaders from Front-Trends. (The second worst conference name ever?)
Step Two: Fork this gist.
Step Three: Respond to this question in your fork: What is one approach you can take from this Mary's code and implement in your project?
Step Four: Totally Optional: take a look at some of the other forks and comment if the spirit moves you.
That was super cool to watch! I thought her explanation of tick and updating was really clear. I also thought it was interesting that the bodies array held three different object types. I think I have a few takeaways I'd like to hang on to.
Step One: Watch Writing Testable JavaScript - Rebecca Murphey from Full Frontal 2012 (award for worst conference name ever?)
Step Two: Fork this gist.
Step Three: Respond to this question in your fork: Consider the four responsibilities that Rebecca lists for client side code (hint: they're color coded). Respond below with your thoughts. Did any of the responsibilities that she lists surprise you? Do you feel like you mentally split your client side code in IdeaBox and other past projects into these responsibilities?
I had a few good takeaways from this, but it really wasn't that easy for me to separate what she was talking about into the four responsibilities. I don't feel like my IdeaBox in any way split this up, and I'd love to try refactoring it as a practice exercise. I think in Rails apps I had gotten to the point of splitting things up nicely in the models, views, and controllers, and this talk made some points that I could connect to that
- Wanted to look at a fun tool that can be used in education. I stopped playing music a long time ago, and want to find ways to start playing around with it again. Know there are lots of musicians here.
- Developed in 2012 by Sam Aaron at U. of Cambridge
- A free live coding synth based on Ruby for everyone originally designed to support computing and music lessons within schools.
- An open source programming environment originally designed to explore and teach programming concepts within schools through the process of creating new sounds.
- Three core domains:
- Art: express yourself and ask new questions of music and notation
- Technology: explore questions related to liveness, time and concurrency in programming languages
Respond to this question in your fork: "What are some of the balances and trade offs between different sorting algoritms?" | |
Steve, did you make us watch this solely because they refer to "JerseyScript"?? | |
- Lexicographical sort: if you just call sort on an array of numbers using js sort, (Array.prototype.sort), it doesn't sort by value but lexicographically. Computer doesn't know they are integers unless we tell it. Need to give (a, b) as args and return (a-b) for ascending sort. | |
-Important characteristics of sorting: stability, runtime analysis, implementation | |
-stable sort maintains relative order with items that are equal | |
-runtime analysis compares time and complexity of sorting algorithms. helps determine best sorting algorithm. Big O is worst case. |