So, here are random thoughts from week 3. The whole thing's going too fast to sit down and write something properly, so I'm sticking with the rambly format for now.
Test -> fail -> code -> pass -> refactor
Every time we write a test, we need to watch it fail. This means you very quickly become comfortable with failure. And slightly less quickly become comfortable with reading failure messages.
Readability is king. Not the CodeWars (and, to be honest, my) idea that the least code is best. You want short methods (ideally with only one responsiblity)
Enrique seems more... opinionated than Evgeny. There are ways he thinks things should be done (i.e. text editors should be devoid of helpful information and make no sense...), and he is less careful about taking the usual teacher's neutral stance.
One of his points is that actually, if statements aren't that simple - they introduce cyclomatic complexity (branching trees of possibilities). He also starts FizzBuzz by working out what it knows, which is odd...
Relatedly, seeing (a) different ways of coding, and (b) good examples of code, is unbelievably valuable, every time it happens. And it seems to happen a fair amount here, which is nice.
Push the 'how' down. Essentially, make the top level methods nice and readable. Or, you know, stuff the mess into cupboards so the front room looks nice for guests.
Classes are a bit like Platonic Forms. This is basically a useless observation for everyone without a Philosophy degree (so, um...), but it helped me. I mean, I'm not sure Forms could inherit, but having a similar concept to make an analogy to always makes the first steps towards understanding so much more pleasant.
Classes also make code more readable, and I hear that's pretty important.
Should adhere to the single responsibility principle, which says what you think it says. This is also true of methods in classes. Everything should be simple. Everything should be clean. Everything should be readable.
Generally, everything in Ruby is an object or a method (I mean, this isn't actually true, but it kinda is). Which is nice, in a way - keeps things simpler. Well, until you notice that classes are objects (instances of the Class Class, of course...). And then the differences between instance methods and class methods... and how they actually work... and oh look, it's confusing again...
Had a talk from Gearóid O'Rourke on working with designers. Kept imagining myself on the other side of the conversation. Have to keep reminding myself I'm meant to be a developer now... Which is weird to even type...
His general point is that it's always going to be helpful to collaborate with everyone else on a project. Designers and developers need to talk more, especially, but it's true for people doing more similar jobs, too. Basically talk to other people more - it turns out they're generally not that bad.
You can create methods called value=(arg) which let you set a value with value = arg. This definitely feels like cheating.
Enumerators are weird.
Oh, there are also Modules. They're a bit like classes that can't be instantiated. They also make my ontology a little more cluttered... but the code cleaner...
Played the Command Line Mystery game. Took notes in a notebook. Solved a murder. Felt amazing. May drop out and become a PI.
There's a way of doing named arguments in Ruby. I can't make it work some of the time. Would like a better grip on it, even though I'm not sure it's that useful. Would also like to be less insistent on trying weirder ideas when pairing...
We're meant to be using the scientific method. Which is pretty in keeping with my attempts at being vaguely analytic about things. Apparently there are some HTML/CSS novices who just throw random code at the screen trying to make things work. This is shocking news to me.
Methodology is more important than knowing fancy code features. Learn the basics well. Learn the principles of good code design. That's what'll get you through.
London likes to use Mocks in tests, keeping class test independent. Chicago likes to use other objects in class tests. I suspect I'll try to follow London and end up following Chicago as it makes some things easier... There's only so far municipal pride can get you.
TDD is actually about designing code. Don't forget that. The point of small tests is to shape the code. Not just to be difficult.
Apparently it is possible to make a joke website based on a drunk suggestion and subsequently forge a career off the back of it. Thank you WeMakeAwesomeSh.it for cementing my new life plan.
I mean, they don't really pitch for work, they just do stuff they think is cool and makes them happy. I'm not sure how much this is a teaching point, but you can't help but be jealous.
Evgeny's really good at code. Seeing good code is really nice. Gives you something to work towards (however far away it may be right now...).
Week's test was like the Essay paper: so much easier with decent planning. Spent the first hour or so just writing down what everything did, which then made the resulting coding so much more pleasant. Knowing how things are going to work is a good feeling. Hope to be able to try it more in future weeks.
Testing randomness is a pain, though
So, testing is great, everything should fail first, and readability is pretty much the best (in the code - this is allowed to all be nonsense).