I didn’t realise that this was a two hour lab, and was about to pack up before checking my timetable again. Since I do have another hour in here, I may as well do this personal blog that we need to be doing for this module (and most modules, actually). Usually these are private between student and lecturer, but since I’m all about being open, why not share it here too? (Plus, this is a much nicer editor.)
This class is Agile Software Development, so it naturally uses Ruby on Rails, which is known for it’s fast pace, don’t-repeat-yourself development cycle. Pretty perfect fit then. I’ve never used it though, but it’s getting more and more popular. All the hot projects on Github are ruby ones, so it looks like the in language at the moment. I remember when Twitter changed from Rails to some other language though, because Rails just wasn’t scalable enough for them.
In the labs we’re using Instant Rails, but I think I’ll likely just install Ruby and Rails myself on my laptop manually, since I already have MySQL and Apache running. Hopefully that won’t be too hard.
We’ve mostly been playing around with the IRB today.
Coming from PHP, it’s pretty obvious how variables are treated differently. Doing something like
$foo = "blah"; var_dump ($foo * 10);
Would output 0; $foo is assumed as an integer, since * is an operator that works with numbers, and it’s assumed 0. 0 * 10 is 0.
But on Rails
foo = "blah" foo * 10
Here the * is treated as more of a method, than an operand, in that it takes notice of it’s context and has been overloaded, sort of. Because it’s a string in context, it has a different functionality. That code would return “blahblahblahblahblahblahblahblahblahblah” (“blah” repeated ten times).
It feels like values are treated more as objects can just … values, really. Literal values can have methods too (inherited from their value type, I guess).