The Blog (and Quines)
Today is a little quieter on the coding front. Having finished the challenges and extra work we’ve been given, I’ve been left with some time to consider some other things that we’ve been advised to work on. This blog for example, something I’d never really considered doing before, but is apparently a very good way of showing your progress and reflecting on learning. It’s useful for when we approach the end of the Apprenticeship programme and have to produce evidence.
For me writing a blog is very strange, I don’t often take time to reflect on what I have done in a day, it’s not really my style, but I can see the benefits. I will be trying to maintain this blog going forward, and have also gone back to cover the days I missed. From now on, the blogs will be from that day/ the day before and be much more current rather than retrospective!
Another thing Makers Academy have suggested we work on on is a GitHub CV. Of course currently it’s a little bare, we haven’t had many proper projects to talk about on there and my experience is slim, but as the weeks go I can keep it updated.
Today I also did some reading about quines in the various program languages. A quine is a program that prints out its own source code (without reading in and outputting it’s source file). There were lots of examples of quines, although as people try to make them shorter and shorter they are hard to understand. The one blog which helped me understand it was here.
The example given still looks a little weird because its all put on one line to save space and make it as short as possible, so I rewrote it myself as an actual method to see how it worked:
def method;
“def method;;end;puts method()[0, 11] + 34.chr + method + 34.chr + method()[11, method.length-11]”;
end;
puts method()[0, 11] + 34.chr + method + 34.chr + method()[11, method.length-11]
In the afternoon we had a workshop on TDD and were given a file to work on. I understand a lot better now how it works, and realise that there is lots of matchers in Rspec to work with which is great. TDD makes sense to me as a logical approach to coding, just need to watch out for tests passing for the wrong reasons. The coaches advise was to comment out the actual Act part to see if it still passed, if it fails then you know it’s working. Act is one of the three A’s of TDD; Arrange, Act, Assert.
Arrange is where you set out anything you need to do before starting the test, like initialising a class or defining variables.
Act is where you run the method or code that actually does the test.
Assert is where you tell the test what the result you are expecting is.
Josh's Blog 