How To Become A Ruby Developer

23 June 2016

A webinar where I talk about Ruby, Rails and demonstrate submitting a pull request to Homebrew.

Presented for CareerFoundry in 2016.

Show transcript

0:00 Okay, so we've started the webinar and we attend our, just join in then, and we'll just start
0:15 the broadcasting.
0:16 Hi everyone, welcome and thanks for joining our webinar.
0:27 I'm Laura, our special guest speaker, Mike McClade, Senior Commander at GitHub.
0:31 I'm Laura, and I'm a career friend of mine, the go-to place for people who want to choose
0:35 their peers to tech and get job sale up.
0:37 Today we've got some really exciting content for you guys, including insight into working
0:41 life at GitHub, advice on becoming a developer, and even a live group demo for Q&A from KVN,
0:46 so stay tuned.
0:47 I want to encourage you guys to use the questions sections for anything you want to ask Mike,
0:51 and feel free to use the chat section for comments or your general thoughts.
0:55 Without further ado, I want to introduce you to Mike.
0:58 Mike, keep it awake.
1:00 Hi everyone, thanks for coming along.
1:05 I'm going to speak to you today a little bit about my experiences in my career and the company
1:12 I work at at the moment, which is called GitHub.
1:14 Then, as Laura mentioned, I'll show you a little coding demo on Homebrew, which is a project
1:20 that's written in Ruby that I kind of work on in my spare time.
1:23 and then speak to you a little bit at the end about becoming a Ruby developer.
1:30 And I'll touch upon the relationship between Ruby and Rails and stuff like that as well.
1:35 So starting off with what I do.
1:37 So my name is Mike McQuaid, as has already been mentioned.
1:41 I've been working full time as a software engineer since 2007, when I graduated from the University
1:47 of Edinburgh.
1:48 And I've been a homebrew maintainer since 2009.
1:51 Homebrew is that open source project I mentioned that I'll show you the kind of coding demo of.
1:55 And I've been a senior engineer at GitHub since 2013.
2:00 So I'll give you a little outline through each of my little steps, through my work stuff, through
2:07 my open source stuff, and then what I'm doing at the moment.
2:11 So I'm originally from Edinburgh in Scotland, I studied at Edinburgh as well, I studied a degree
2:18 in computer science and management science, which is basically computer science and business
2:22 on the side.
2:23 I did that 2003 to 2007.
2:26 I'm relatively uncommon in my company and in my career, I guess, in general now, because
2:32 that's a very traditional way to go into software development.
2:36 If you haven't done a degree in computer science, then that's completely fine.
2:40 And I'll talk more later on about that, but it's not something to worry about.
2:44 And with the various code academies and career recovery and all the kind of resources that
2:49 are on the internet now, you can learn enough without going through formal education anymore.
2:55 So as part of that program, between my third and fourth year, I did an internship at a company
3:00 in Edinburgh called Wolfson Microelectronics, where I was mostly writing C code for audio chips.
3:08 I was writing code that dealt with the Linux kernel and driver code and stuff like that for there,
3:13 which basically means kind of the code that speaks between the hardware and the operating
3:18 system to kind of provide an interface so the operating system can speak to the kind of
3:24 chips that the company was making.
3:27 The year after that, I did Google Summer of Code.
3:31 I worked using C++ for that and that was for a project called KDE.
3:37 That was my first kind of big foray into open source.
3:40 Then after that, I worked for a company in the UK called BT, British Telecom, where I wrote
3:44 mostly C and C++.
3:46 And then for a startup in London called Mendeley, I was the first employee there.
3:51 They're now a kind of research software company and they have a lot more than just me working
3:59 there and worked for a consulting company called KDAB, which was kind of based around Europe.
4:06 And then I entered the Ruby phase of my career.
4:09 And one of the reasons I kind of have walked you through what I was doing and the languages
4:13 I did it in, but is because it's interesting to see that I think at least that in the software
4:19 field, you can kind of start out doing one thing and you can kind of move on to something
4:22 else.
4:23 I don't think you need to worry too much, particularly in the early days, about finding
4:27 exactly like the perfect fit for you.
4:30 Obviously it's good to kind of go into something that interests you and something that is engaging,
4:34 but it's always possible to move around.
4:38 And in many ways, if you have a career in software and you're there for 10, 20, 30, 40 years,
4:45 you're going to have to move around.
4:46 You're going to have to make changes.
4:47 I'm sure you can all remember what computers were like 5, 10, 20 years ago.
4:52 And the skills that were involved with writing software for computers back then varied quite
4:57 a bit from what they do now.
4:59 So I've had to adapt and I've had to change.
5:02 And that also gives you a chance at each of those change points to kind of think, am I
5:06 doing what I want to be doing?
5:08 Can I kind of move to something else I'm a bit more interested in or whatever?
5:12 So then I worked for this company Alltrails, which was based in San Francisco.
5:16 I worked remotely for them and in fact for KDAB before them as well from my home in Edinburgh.
5:21 And I was writing Ruby with them for the first time, doing Ruby on Rails.
5:27 I had been working with Ruby, as I'll talk in a minute, about in my spare time on open
5:32 source, but that was my first kind of full-time Ruby gig, writing a Rails-based web application.
5:38 And then nowadays at GitHub, I'm writing mostly Ruby as well and Bash, which is kind of, you
5:43 may have heard called shell scripting in the past, and that's a way of interfacing with
5:50 Linux and Mac systems.
5:53 So I kind of end up doing more of those two and I'm not running, although GitHub is a big
5:59 Ruby on Rails application, I end up kind of working mainly in the back-end for there nowadays.
6:05 Right, so on open source, I started with that work with Wolfson Microelectronics.
6:11 I kind of had my first kind of major contribution, I guess, to an open source project, which was
6:14 to the Linux kernel.
6:16 That's the thing that's used in Linux desktop machines and in Android phones and various other
6:22 places around the world nowadays.
6:24 So that was, again, writing in C, then that KDE project through Google Summer of Code and
6:29 C++ again.
6:31 And then the Homebrew project, which is, I'll show you a little bit of live coding with that
6:34 later on, that's what we call a package manager for OSX.
6:38 It's kind of like an app store for things that you run in your terminal.
6:42 There's lots of tools in there which are kind of useful for the developers who use Macs, and
6:47 it's the kind of package manager concept of something that's originally kind of come out of,
6:51 I guess Linux, in desktop Linux, kind of originally.
6:55 So I work on that from 2009 until now, and I'm once known as a maintainer, which means that
7:01 as well as writing code myself, I kind of help review and include other people's code as well.
7:06 And then I have like a little project that I worked on from GitHub called Strap, which is
7:11 like a way of kind of setting up your Mac if you get a new Mac so that you can kind of automatically
7:16 install Homebrew and various other things that you kind of need when you're a developer,
7:20 with a nice little simple script and like a web application to set up your GitHub stuff,
7:25 rather than having to do that manually every time.
7:28 And then I've worked on various other random open source projects over the years, dealing
7:33 with you know across Ruby, C++, but also like Python, PHP, Bash, Objective-C, Puppet, JavaScript
7:39 and various other languages.
7:41 And I say that just to again mention that you can, you know, there's a lot of languages out
7:45 there that are being used for a wide variety of interesting things and chances are in almost
7:50 any job in the industry you're going to end up touching on more than one language at some
7:54 point.
7:55 So I think it's one of those things where like I only speak English, but like many people
8:01 tell me about learning to speak actual foreign languages and then the more you pick up the
8:07 more easy it is to pick up more and more languages and stuff like that.
8:11 Like with kind of a tool belt of a few languages under your belt, it will definitely be kind
8:16 of easy to advance in future.
8:20 Right, so jumping on now to what GitHub does.
8:23 So GitHub is my current employer and I've worked for them for, as I was saying before, about two
8:29 and a half, coming up to three years, they're a company where they basically provide a community
8:37 online, which last time I looked at the numbers, it was saying 50 million people, 38 million
8:42 projects and it basically allows people to collaborate together on building software online.
8:48 If you start working as a developer, not every company obviously, but quite a few companies
8:53 use GitHub now to kind of do their work for developers to interact using something called
8:59 version control, which is, to give you a very brief overview, version control is the way,
9:04 because developers are normally working with text on a day to day basis, version control
9:08 allows you to kind of look back through previous versions of text and work with other developers
9:14 on a project, say, and you can kind of explain why and when you made each of the changes, which
9:19 makes it useful if you're going back and trying to figure out why something was done in a particular
9:22 way.
9:23 GitHub is the 60th most visited site in the world according to Alexa when I looked, I think
9:28 it was last week, which means that we have a whole set of interesting challenges when you
9:33 are working on a site at that scale.
9:37 We use Ruby on Rails for that, but then when you get to kind of a scale where you're kind
9:41 of getting loads and loads and loads of traffic, you have to kind of do interesting things, you
9:45 can't just do everything maybe the way it necessarily comes straight out of the box, because you want
9:50 to try and ensure that everyone who uses the site has good performance and if you have
9:54 a sudden spike of users who visit the site, then that doesn't bring the site down for other
9:58 people and stuff like that.
10:00 And the big thing that got me interested in GitHub and is where a lot of people end up kind
10:05 of discovering it at first, is it's the kind of primary location for a new open source project
10:10 nowadays.
10:11 That's where Homebrew is based and pretty much all the other open source I work on now.
10:15 And the advantage of GitHub is because it's a bit of a community, contributing to any open
10:19 source project on GitHub is broadly similar.
10:22 You open a thing called a pull request, which is basically a way of saying, "I want someone
10:27 to include some code I've written into their project."
10:32 And that's a kind of mechanism where there can then be a discussion and then if they like
10:37 and want to include what you've suggested, then they can merge that in.
10:41 And I'll demonstrate that a little bit later on.
10:43 We can kind of see an example when I do the coding exercise.
10:48 So GitHub, as I mentioned, I'm writing Ruby there.
10:52 Ruby is very widely used at GitHub, both on the main kind of site itself, but also in lots
10:58 of little things in the background, lots of kind of scripts we have running and other
11:02 little kind of tools that aren't necessarily seen directly by the outside world that end
11:06 up kind of supplying the services that make up GitHub itself.
11:12 So most engineers, as a result in GitHub, are writing primarily Ruby codes.
11:16 There's people who write a bit of C, a bit of C sharp for Windows applications and stuff
11:21 like that, but primarily most things are written in Ruby.
11:26 And as I mentioned before, GitHub's probably one of the biggest Ruby on Rails powered sites
11:30 in the world in terms of the traffic and the throughput, which kind of makes it an interesting
11:35 situation to work on.
11:36 And again, it goes to show you may kind of hear various people say various things about
11:41 Ruby and Ruby on Rails, and it's maybe some people might say it's not as cool as it used
11:47 to be, like when it was the kind of hip new thing and stuff like that.
11:50 But it's important to know that, you know, Ruby on Rails is being used to build very serious
11:54 applications that are making real money in the real world.
11:58 And I think personally, it's a fantastic tool for doing that.
12:01 And that's one of the reasons why GitHub uses it is because it's such a good tool.
12:07 And then I personally, GitHub, so I worked for about a year and a half, two years on our product
12:16 called GitHub Enterprise, which is a tool that allows you basically to have your own version
12:21 of GitHub that sits inside your kind of company firewall or whatever.
12:25 And then you can kind of share projects and collaborate and stuff like that without having
12:28 to put your stuff on GitHub, the main website.
12:30 It's particularly useful for companies that either for legal reasons or just cultural reasons,
12:35 don't trust having any of their code outside of the company itself.
12:39 And it's distributed by us as like a virtual machine to people that they can then spin up
12:44 and run.
12:46 And then nowadays I'm mainly working on what we call internally the GitHub platform, which
12:50 is our like API web hooks, basically all the stuff that's not kind of front end coding,
12:56 but it's providing like an interface to either projects inside the company or projects outside
13:00 the company as well.
13:02 And the things I probably am most known for and most enjoy doing are kind of automating things.
13:08 I think that's one of the things that's so great about being in software and being a software
13:13 engineer is, you know, most people nowadays have to use computers to do stuff a lot of
13:17 the time.
13:18 And it's a fantastic feeling once you kind of get a bit of experience under your belt and
13:22 you realize that almost anything you have to do with a computer, you can learn how to do
13:26 it much faster.
13:27 You can go and tell the computer how to repeat operations hundreds of thousands, millions of
13:31 times, you know, in a couple of seconds.
13:34 And that just allows you the ability to kind of take a lot of boring, repetitive tasks,
13:39 for example, and automate them such that they're not nearly as repetitive to perform anymore.
13:45 Right.
13:46 So I'm going to jump now into a little coding exercise that I'm going to do with homebrew.
13:52 So for this, I'm actually going to deal with a real world issue that I was looking at today.
13:59 So this is an example of GitHub.
14:01 And you should also be able to see my screen over here.
14:04 So this is one of the homebrew repositories called Homebrew Brew.
14:10 Homebrew is the name of the organization.
14:12 And then there's Brew, which is the kind of name of the project.
14:16 So one of the other maintainers on this project, a guy called Dom, who's another guy in the UK,
14:21 who has this lovely picture of him and his dog down here.
14:23 So he basically mentioned that he thinks we should do this thing here, which interrogate taps with brew read all on tap.
14:30 So what does that mean?
14:31 I'll give you a very high level overview.
14:33 So as I mentioned before, Homebrew is a way of kind of installing packages.
14:37 It's what we call a package manager.
14:39 And a tap is because Homebrew has like a beer theme, as you might be able to tell from the name.
14:45 A tap is like a third party kind of package and like repository, I guess.
14:52 So if there was something that it wasn't in Homebrew and I wanted to make a few packages in there, then I could go and make a tap and then allow other people to distribute that.
15:02 But what the problem is here that he noted is that in some cases you can have taps which have things in them that are broken and then that causes problems for users.
15:13 So what he's suggesting we do is when you install a new tap, you run this brew tap command.
15:19 But what Dom's suggesting is that as well as this brew tap command, we want to run brew read all, which basically reads through all the files in a tap and make sure that everything valid.
15:30 And then we want to do that whenever we run brew tap, just to make sure that brew tap is actually working correctly and we're not going to cause errors when we do that.
15:40 So I'm going to jump over here.
15:42 So this is a terminal.
15:44 I don't know if many or any of you have seen this before, but this is basically like a way you can kind of type.
15:50 It's kind of like programming, but you can just type almost lines of code directly into your kind of what we call this terminal here.
15:58 So in here these commands he's described, this is how you interact with homebrew.
16:03 So we've got this kind of brew command that you run like that and it's now telling me ways you can use it.
16:08 So what we might want to do is like this thing called the boneyard, which is one of the homebrew taps.
16:17 We're going to go and run brew tap on that because in fact that was my mess up because it was already installed.
16:25 So we'll just untap it before and then tap it afterwards.
16:29 So that's just two commands in a row.
16:32 So we've tapped this homebrew boneyard thing, which means it's been installed.
16:37 So that's actually installing what's a Git repository.
16:41 So basically one of the projects from GitHub, because this is a separate project there, and that's just like installed locally.
16:48 And this is all fine and it's all working.
16:51 But what we want to do, as Don mentioned, is go and check that when we run this brew tap, it's actually going to go and check what we want it to do.
17:00 So I'm going to kind of walk through almost from the outside in of the Ruby code here.
17:04 So this brew.rb file, this is what it's called basically when you want to brew itself.
17:11 There's actually a bash script that calls this script, but we won't worry about that because we're not doing anything about bash today.
17:16 So this goes through and does various little checks to begin with and stuff like that, but we'll ignore them.
17:22 And we'll start off down here effectively.
17:24 So we have this thing where we say if we've got a cmd, which is short for command, then we're going to go and like require, which means pull in another file, this command from this directory in here.
17:40 And so in this case, the command is going to be tap because we've typed brew tap.
17:46 So that's what the command is.
17:48 So then we can jump through into this file in here, which is this tap command file.
17:52 So we've got a little bit of like almost help instructions at the top.
17:55 So that's what you'd see if you type brew tap dash dash help.
17:58 So we see that like this.
18:00 And then we can look through in this various options and things that are being handled.
18:04 But the one we care about is this one here.
18:06 So we have specified a tap in here, which is, this is saying get the first argument, the argv, which is a way of saying the values of all the arguments.
18:19 The first named argument, which is one that doesn't start with two dashes like that as an option.
18:25 And we'll get the first one in there.
18:27 What you may see is a lot of programming languages sometimes use zero instead of one to indicate the beginning of a list of array.
18:35 That's something you might notice.
18:36 So this is actually saying the first, but it's indicated here by a zero.
18:41 So we then get this tap in here and then we run this tap dot install method.
18:47 So what that's going to do is then we jump through to this file here and then we have this install method.
18:54 And I'll walk through this one in a bit more detail and then we can go and like actually write some code to do what we want to do.
18:59 So this is this install function here.
19:02 It takes one parameter, which is just options, which defaults to just an empty hash, which is just a way of providing keys and values in Ruby.
19:12 So we go down here, various options are handled.
19:16 If the tap is already installed, then it raises a tap already installed error, which basically equates to doing nothing.
19:24 So that's what's happening if we do here.
19:26 We've already installed it, so it's actually going to do nothing.
19:29 And then it's going to make sure git's installed.
19:33 Git is the command you use to kind of get things from GitHub.
19:36 And it's basically just checking that that's still there.
19:41 And then if it's installed, then there's various other things we can do in here, but we can ignore that for now.
19:50 But this is what we care about here.
19:51 So if you remember, it said that tapping thing there and then started downloading in there.
20:00 So we're basically, what we've done here is we've built up the arguments we're passing to the git command.
20:06 So that's going to call git and then all of the things in args.
20:11 So that's going to call, let's say if I was typing here, git clone the requested remote,
20:17 which if it's homebrew boneyard actually ends up being a GitHub URL.
20:24 So that's like that.
20:30 And then the path it wants to go to.
20:32 And that's basically just a location on disk.
20:34 So in this case, that would be user local, which is where homebrew is installed.
20:40 Library, which is just a directory for homebrew stuff, basically.
20:43 Taps, which is all the third-party repositories, then homebrew, and then homebrew boneyard.
20:48 And then that's going to be the contents in there.
20:52 And then the depth one, we'll ignore that.
20:55 And then -q, which is quiet, which is basically just if you pass the quiet option, which we have in here.
21:01 So then this calls it with a thing called safe system.
21:05 So what that does is that's basically making sure that the command runs correctly.
21:11 If it doesn't run, like system will just run this command as is.
21:15 And then if it fails, it won't do anything.
21:17 Safe system, if this command fails, then it will then throw an exception, which is basically a way of throwing an error.
21:24 And something has to handle that error.
21:26 Otherwise, it will bubble all the way to the top of the application and then cause the application to fail.
21:30 So we're going to go and replace this command.
21:33 So let's do git mic instead, which is not a real command, to see what happens there.
21:40 So again, I have to untap it before because otherwise it will just do nothing.
21:43 So here we've got this error, failure while executing, blah, blah, blah, blah.
21:48 So what we probably want to do in here is we want to go and add in here another safe system.
21:55 If you remember what Dom said he wanted to do back here was let's run this brew read all.
22:01 So in here we're handling things if these commands fail.
22:06 This is this rescue.
22:07 This is the exception that got thrown by the safe system here.
22:11 And then it's getting handled by this or this.
22:15 So we can go and do the same thing and we can do brew and then read all like that.
22:23 So we can go and say after we run git, run brew read all, but then we also want to go and pass in the name.
22:32 But because that would just type brew read all name and what we want to do is use a variable there instead.
22:40 So we can remove it from the quotes and do brew read all name like so.
22:45 So then when we run this, it's going to go and run like so.
22:53 And then tap homebrew boneyard and then run brew read all.
22:57 And because that works, it's all going to be fine.
22:59 But what we can do is again, we're going to replace this with a fake command that doesn't exist, run this again, and then make sure that it works the way we expect it to.
23:10 So yeah, so we get this unrun command read all, failure while executing brew read all to homebrew boneyard.
23:17 And then this is the kind of interesting slash slightly clever bit.
23:20 So due to some code that's already there, thankfully we don't need to write this, we have this homebrew boneyard directory.
23:28 And what's going to happen is if we try and tap that, it's going to make sure that what it should be doing is deleting that directory.
23:37 So in here we've got this path.parent rmdir if possible.
23:42 But what we want to do is let's go and make that a little bit stricter and say that we want to, no matter what happens, we want to go and delete that directory in there.
23:52 The one that we've just created on the tap.
23:55 So we'll get this path and we'll do file utils rm-rf and then we'll pass in that path.
24:07 So that's basically the equivalent of doing rm-rf which stands for remove a file, remove it recursively, which means if it's inside a folder, if you pass it a folder, it's going to remove that.
24:17 And then f which is just force.
24:20 So let's try this again, see whether afterwards it deletes this.
24:24 So we can now see that this home rm-boneyard directory is now gone.
24:33 So that deleted it as expected.
24:36 So we can then go and do this.
24:40 We can remove this here.
24:43 Try this once more.
24:45 Yep, so that's deleting it as expected there.
24:57 So we're going to put back that to the correct one.
24:59 What it would look like if it failed properly would be, and again this is tricky because I can't make something that's actually being used by people fail.
25:07 So I'm going to go and, like this is what we call a formula file in homebrew which is basically just a little description of what, how we're going to install these things.
25:19 So I'm going to go and basically make that invalid and then edit it.
25:22 So I've made that invalid.
25:26 So then brew read all in that case, if I run homebrew boneyard like that, that will then fail.
25:33 And then that's the same error that, if that ever happened, if someone made a mistake there, then that would then do the same thing as what we faked before with brew read all two.
25:43 And then that will fail up and delete that and stop causing any issues for people.
25:49 So what I'm going to do now is I'm going to have a look at my changes with the git command.
25:55 So git diff means show me the differences that I've made here.
26:01 So then I can go and see that I've, the new lines I've added are in green and lines that have been deleted are in red.
26:10 So I can see that I've added these two new lines and then I've deleted this line here.
26:14 So what I'm now going to do is create a new branch in git.
26:19 So let's create a new branch called tap read all.
26:23 I'm going to check out that branch so I can go on it.
26:28 And now just check that all my changes are there.
26:37 And then I'm going to commit that, which means it's kind of like saving a change if you haven't used version control before.
26:43 This is like saving a file.
26:45 But what it does as well as saving it, it will go and ask you for like what have you actually done in here.
26:50 So you see it's saying please send to the commit message for your changes.
26:55 And then it's going to ignore all these lines down there.
26:57 So I'm going to say prefix it with tap because that's what I've touched here.
27:01 Run read all when tapping.
27:06 And then I'll like writing an email, but this is my almost subject up here and this is the body down here.
27:14 So I'm going to write a little message.
27:15 So say this will let you read rather than me dictating to you.
27:21 And then I can then pass in a little like this number here, which is the issue number.
27:39 And I can say fixes that, which means that that will, when this is, if this is merged at some point, this will go and then close that issue at the same time.
27:49 So I'm now going to go and push this up to GitHub.
27:54 So I'm going to say push tap read all.
27:59 I'm going to push it up to my GitHub rather than homebrews itself.
28:06 So I can then submit a pull request from my one like you might do.
28:11 And then this branch called tap read all.
28:16 So I've now created this new branch on my Git repository here.
28:20 This is what we call a fork in GitHub, which is basically like my own private copy of this repository,
28:28 which means I can kind of modify it and then send changes like this.
28:32 So I'm now, I've got this thing.
28:34 This is basically saying I've recently pushed a branch called tap read all.
28:38 And then I'm going to do this compare and pull request thing.
28:41 There's then a little checklist that they want me to fill in to basically say, have I followed various guidelines?
28:49 And am I sure that it works basically?
28:57 And now I can go and then click create pull request.
29:01 And then I've got this nice little pull request on the brew repository,
29:05 which this is something that you could view on the internet live,
29:08 which now has basically a request for the other people who work on this project to look at this.
29:14 They could then click at this files change.
29:16 That's similar to what they saw before that you have this is the line I've added,
29:20 this is the line I've added, this is the line I've deleted.
29:22 And then they can go and then click through here and have a look.
29:25 And then if I refresh that, then we might even get to see.
29:30 So what will happen as well, it's going to take a minute or two to start.
29:35 So I'll not wait for it.
29:37 But as well, what will happen in a minute is that this little brew test bot,
29:41 that's kind of marked the issue is in progress.
29:43 It will go and check out my changes, make sure that everything seems to work the way it's meant to work.
29:50 And then kind of try it out and then report the status back and report whether that passed or whether it failed.
29:56 And if it failed, I can go and click through and see what the problems are.
29:59 So that's all for the coding section for now.
30:05 And I'm going to jump back into the presentation again.
30:08 So becoming a Ruby developer, which I guess is why some of you are watching this.
30:16 So I think Ruby is a really great language.
30:21 It's my favorite language that I've worked with.
30:23 As you probably saw before, I've kind of dabbled with a few different languages over the years.
30:28 And I've stuck with Ruby because it's my favorite.
30:32 I mean, the top thing there, I think it's fun to write in.
30:36 It's nice because it allows you to be very expressive.
30:40 To get technical, it is both an object-oriented language and a good scripting language
30:45 and a functional programming language, which means that you can explore lots of different ways of programming
30:49 while you write Ruby in any application, really, which is good.
30:54 And as a result of allowing you lots of different ways of expressing yourself,
30:58 it allows you to kind of learn while you're working with Ruby and learn more about Ruby,
31:02 learn more about other languages and use those to kind of solve things in very elegant and very concise ways.
31:09 And that's something that I tend to enjoy doing.
31:12 It's really highly in demand.
31:14 It's if you look around like the jobs that are available for software engineers nowadays,
31:19 particularly for entry level software engineers, there's a lot of jobs that are available writing Ruby on Rails applications now.
31:25 It's used for a lot of web applications in the wild.
31:29 And as a result of being highly in demand, it actually pays reasonably well as well,
31:35 compared to maybe some other jobs and some other things in the industry.
31:38 So that's a plus point, I think, as well.
31:40 Ruby on Rails is the main kind of framework behind Ruby.
31:45 So to explain the difference between the two, Ruby is the language.
31:48 So what I was doing before with Homebrew, that was all written just in plain Ruby.
31:54 And Ruby on Rails is a way of using the language and it's what we call a framework,
31:59 which is a way of using the language to build web applications.
32:02 So it's a relatively opinionated way of setting up Ruby and lots of kind of templating and lots of provided functionality for you.
32:11 So that if you're making a web application, you kind of have your application structured in a sensible way that's kind of recommended by people who've been kind of doing this type of thing for a long time.
32:19 So that's another thing that's kind of, I think, really good about Ruby, because Rails is widely used, because it's well documented, because it's kind of quite friendly.
32:28 And as a community, it means that the whole of kind of Ruby, whether you're working with Rails or not, kind of benefits for that as a result.
32:37 There's also these things called Ruby gems. You'll find when you become, the more and more experienced you become as an engineer as well,
32:44 that you often will see the same problem in, you know, one, two, five, ten, a hundred different places.
32:51 And you don't want to write the same code every time and repeat it again and again and again.
32:56 So you can share code between your projects by copying and basing it or kind of sharing code in different other ways.
33:04 But what a really nice thing is to do is when people kind of work on open source projects is to go and make a thing called a Ruby gem,
33:11 which is like a little standalone library in Ruby, which you can then add to your project, which then allows you to kind of take out little bits of functionality,
33:19 which then people can pull into their projects when they just want that little bit of functionality.
33:24 Like, for example, when I was working with today, the CEO of my company made a Ruby gem a long time ago called Rescue,
33:32 Rescue, which is a queuing system, which basically if you have a bunch of kind of jobs that need to run in the background,
33:37 for example, in a web application, if you want to, you know, if a user clicks on something,
33:42 then you run a bunch of code, which then generates what they want to see, and then you give that all back to them.
33:48 But if you actually wanted to do something like, you know, process a PDF in the background, which might take an hour or two,
33:54 then you would go and make a background job, which would do that, and then maybe later on send them an email.
34:00 So Rescue is a solution for doing that. And one of the nice things about that being a Ruby gem and that being open source
34:05 is that it means that every time someone using Ruby or Rails now wants a queuing system,
34:10 they don't have to go and write it from scratch every single time. They can reuse an existing tool like that.
34:15 And finally, I think the main benefit of Ruby nowadays is that it's pretty stable. It's been used for quite a long time.
34:24 And as a result, it's got a wide body of knowledge. It's not really, really buggy. It's not experimental.
34:31 And you have big companies that write various posts and things like that and people who can help you on how to kind of make it scale
34:40 and run at a very high level of performance for, well, not a high level of performance, maybe compared to some other languages,
34:46 but certainly you can run Ruby in such a way such that you can run very performant websites and applications.
34:53 So finally, if you want to learn Ruby on Rails, there's some great resources and some great, I guess, little tips.
35:03 I think the first thing I would say is if you're trying to learn any language or framework or anything,
35:08 the easiest way to do that is to try and solve problems you already have, like rather than going and saying,
35:13 OK, I'm going to go and try and follow a bunch of tutorials and things like that and just do whatever other people tell me to do.
35:19 The best way of learning, I think, is to try and find some problem that you or maybe a friend or a family member
35:24 or someone like that has and try and figure out a way of solving that using Ruby or using Rails.
35:29 And that's, in my experience, a way that will get you much more involved in the problem
35:34 and much more equipped to kind of see how you solve real-world problems rather than just trying to solve tutorials.
35:41 That's important. Obviously, tutorials are important when you're right at the beginning, but you should try and almost start
35:46 what we call in software, kind of scratching your own itch with these type of things as soon as you can.
35:52 There's some great resources online.
35:54 To mention just two, there's Career Foundry, who's obviously hosting this webinar.
35:58 They've got a nice little post about whether you should learn Ruby on Rails and the links down there.
36:03 You should be able to find it on their site.
36:05 And then the Ruby on Rails official documentation, which they call the Rails Guides, which is guides.rubyonrails.org.
36:11 They're really great. The main one, I think, that's Ruby, I forget the exact name off the top of my head,
36:20 but I think it's at the top of the page when you go there.
36:23 It walks you through basically building more or less a Twitter clone from scratch with no program knowledge
36:28 and helps you to understand how a modern web application kind of fits together, all the components that go in there,
36:34 how your browser speaks to the server, which speaks to the database and all these type of things that you need to learn.
36:40 Another really useful resource, I think, is Heroku.
36:43 So previously, five or ten years ago, whenever you were running applications and learning these things,
36:52 you would have to figure out a way to have a server somewhere that you can install this on if you wanted other people to see your stuff.
36:59 But the great thing nowadays is Heroku makes it very easy.
37:02 If you just write a Ruby on Rails application more or less by default and you use Git like we saw before,
37:09 then you can just push your repository to Heroku.
37:14 Heroku kind of magically figures it all out and will just spin up a web application for you.
37:18 And then you can actually do that for free for small applications that don't get much use or load.
37:24 But for bigger applications, then you can start asking Heroku for more resources and that costs money.
37:31 And then if you're working in a team or even if you're working by yourself trying to kind of get into open source,
37:37 then you can create public repositories, which are ones where anyone can see the contents of them for free on GitHub.
37:43 That's a really good way to learn as well.
37:46 Or you can set up private repositories if you want to for, you can have as many as you want for $7 a month.
37:52 So I guess those are the main resources I think are important when learning Ruby on Rails to start with.
37:58 And I think hopefully I've given you a little overview of why you might want to learn Ruby on Rails
38:04 and why you might want to learn Ruby and showing you a little bit of how Ruby works.
38:08 So I think we're going to now go if anyone has any questions.
38:12 Great question.
38:13 So I think for building a portfolio, the best thing you can do in my opinion, and I guess you might see from my experience is to work.
38:19 on open source, to try and make little projects and try and make little open source projects out of them so people can see them.
38:29 It's really helpful for people to be able to go and look at your code.
38:39 Now some people may feel intimidated by that and may feel that if people are looking at their code, they may, you know, people might judge them for it, whatever.
38:50 But I think one of the great things about this industry and about going into programming in general is that everyone knows that everyone makes mistakes.
38:57 and everyone knows that everyone knows that everyone has to start somewhere.
39:12 So going out there and working on open source is a really good way to kind of learn out there in the open and be able to kind of solicit feedback from other people while you do so.
39:20 And it's much easier if you have a friend who's a more senior developer, say, to be able to just post them like a link to your GitHub page and a particular line of code or whatever than it is to kind of, you know, start zipping files up and sending them across the internet like that.
39:35 So I would say that's the best way of doing it.
39:37 And then if you're working on stuff for a company that isn't, you're not able to open source it for whatever reason, I think it's kind of nice to just have a nice little simple homepage for yourself and have a portfolio page.
39:49 Just take some screenshots of whatever you've been working on, stuff you're proud of and just write a little bit about the projects you worked on and why and what your contribution was to it.
39:58 Obviously, I personally still have like a more formal CV or resume as well, but it's nice to have like something a bit more visual so that you can kind of point people to that as a portfolio.
40:07 Thanks Nick, that was a great answer.
40:12 And we've had another one on Twitter from Daniel Cervantes. He asked, "What are the dos and don'ts when learning a new programming language?"
40:22 Great question. So dos and don'ts when learning a new programming language. I would say the main do, as I mentioned before, is to try and work on something that kind of interests you and ideally a problem that you're solving for yourself.
40:36 Another one I would say is to try and work on something small to start with. Try and do - I guess that's a do and a don't - but do make sure you try and make small little things that you can deliver in a small amount of time.
40:52 Even if that seems very, very simple, even if it seems trivial to start with. Try and work on things that you can kind of get to completion rather than having, you know, a hundred little projects that are all 90% there.
41:05 Because you'll learn a lot more by actually what we always call in GitHub, like shipping, by actually releasing something to other people and actually releasing something and going the whole train through from writing code to pushing up to the internet to actually getting on Heroku and being able to click on it.
41:21 And being able to click around the site. Those are all important skills to learn more than just necessarily writing the code. So going end to end there is really good.
41:31 And I think another don't is just try not to get disheartened. I think one of the tough things with programming is even when you've been doing it a very long time, there's still days and hours and minutes and weeks, even sometimes where you feel really stupid, because you're doing something which a lot of the time has never been done by anyone before.
41:49 So it's natural that you're going to feel a little bit lost sometimes. And you just need to kind of try and push through that and try and take satisfaction in the kind of victories when you do manage to figure stuff out.
42:02 Another final one, I guess, is when you're starting out, particularly if you work in a professional capacity, if you're able to get kind of a job relatively early on. The thing I always advise people who are more junior is if you ever make a mistake, if you're ever lost or screw up or whatever, just make sure you are kind of vocal about that.
42:20 Make sure you raise your hand, say, I don't understand, say, I think I've broken something, whatever. And people understand that people, you know, respect that, because ultimately, as I've mentioned a few times, we all make mistakes in programming.
42:34 And what's important is not whether you make mistakes or not, but how you make mistakes and how you rectify them. And a big part of that when you're working in teams is making sure everyone in the team knows when you've made a mistake, not so that anyone can blame you, but so that everyone can help you and jump on board and make sure that you all work together on kind of finding a great solution.
42:53 Great. Thanks, Mike. We've had a couple from the audience. So I'll start with this one from Joshua. Ask how long it took you to learn Ruby?
43:09 So I think it's interesting with learning a language, like learning a lot of things in life. I'm still learning Ruby. I learn new things about Ruby on a day to day basis, I think.
43:21 But I probably, I guess to get comfortable with the language such that I was kind of happy applying for jobs, I was working my free time, but it kind of took me like, probably like a couple of years before working in my kind of evenings and weekends before I would have been happy kind of saying that I could kind of do that comfortably for a living.
43:41 I don't think that's the case if you're kind of more dedicated and more focused on just that and you don't have another day job on top of things.
43:49 And I think one of the differences as well is that I was not almost following my own rules.
43:57 I was not going and reading through all these resources and stuff like that. I was kind of just figuring it out as I went along.
44:02 I think a really good thing to do is to make sure that at the same time as building stuff, you're just doing a lot of reading as well.
44:08 I think the most useful thing for me, which is probably a bit in depth for beginners, but was when I've been working with Ruby for about maybe a year, maybe two years or so, I read the kind of official Ruby programming language book, which kind of details like everything you can do in Ruby.
44:24 And at the time I didn't necessarily understand all of it and I didn't necessarily remember it all, but it was kind of good to get that overview of like everything the language can do so I can then go and Google it later.
44:38 Okay.
44:39 Great.
44:40 Great.
44:41 We also had one from Patrick.
44:44 He asked, is there a good precursor language to learning Ruby?
44:48 He noticed you did C and C++ first.
44:51 Sure.
44:52 I would definitely not recommend learning C and C++ first.
44:57 That will be more confusing.
45:00 I think Ruby is a really great language to start with.
45:03 I have introduced other people to programming and Ruby has been their first language and I think that is a more pleasant experience.
45:10 C and C++ are lower level languages, which means that you have to do more stuff yourself.
45:18 There's less stuff that's provided by the language for you and you're kind of closer to the machine, which means you have to have to write well in those languages.
45:27 You need to have a better understanding of what is going on inside the computer than I think you do to learn Ruby.
45:33 So I definitely think Ruby is the best thing to jump into first.
45:38 Ruby and or Rails at the same time are kind of a great way to just get started on programming.
45:47 We have also had one from Nestor.
45:52 He asked, why should I learn Ruby over JavaScript, which recently there's been a lot of hype around JavaScript frameworks like Node, Angular, Ember, GoC, Meteor, etc.
46:04 I mean, I don't want to, I've never written a production application, for example, in Node, so I wouldn't want to kind of critique Node.
46:14 Node, I think JavaScript versus Ruby, I think Ruby is a more modern language than JavaScript.
46:21 JavaScript is still getting a lot of work on it and it's changing a lot of ways, but because Ruby is more modern in its conception, it's been able to do a lot of different things.
46:33 I think the syntax is a lot more, I guess, human readable, I would say.
46:37 It's a lot more expressive in what you can do with it, I think.
46:42 There would be a lot of people, I'm sure, who would disagree with that.
46:46 But personally, I think it's a nicer language and it's a better language.
46:50 I think a more pragmatic argument would be that Ruby on Rails has been around longer than Node.js.
46:56 So although the internet and Twitter particularly may go and get more excited about certain languages and certain topics,
47:04 there's definitely a thing where more jobs are sometimes available in slightly older technologies because they've been around for a while
47:15 and because companies know how to work them at scale, because there's companies who provide consulting and training and all these type of things around them.
47:23 So if you were asking me in five or ten years, maybe by that point Node would be a much better choice than Ruby, but I think today Ruby is a better choice for those various reasons.
47:37 And, as I said, as a preference point of view, I've enjoyed writing Ruby a lot more than I've enjoyed writing JavaScript.
47:47 Next, Mike, and another one from Josjeet.
47:51 He has asked what problems you have encountered working with Ruby.
47:56 That's a good question.
47:58 So I guess the problems you encounter working with Ruby are, I guess one of them would be,
48:06 you can't do Ruby for everything.
48:08 The point that was made previously about Node.js, one of the things that is appealing to some people about Node.js,
48:14 which is a framework that you can use to write JavaScript, is that you can write JavaScript on the server,
48:21 but you can also write JavaScript in people's web browsers on the client as well.
48:25 So you can basically get away with pretty much only writing JavaScript and not having to understand a separate server and client side language.
48:35 So I guess you could say that's a problem with Ruby is that you can't do absolutely everything in it.
48:41 And similarly with Ruby, it's not as performant for things which are very, very CPU heavy.
48:50 So for example, if you were speaking to something on the internet and every time you sent a message,
48:58 it took a second to get back to you or whatever, then in those cases, Ruby would just be just as fast as everything else.
49:04 Because in that case, the slow thing is the internet connection and not the language itself.
49:09 But if you're speaking to something which speaks back to you very, very fast,
49:13 if you're speaking directly to the CPU and trying to crunch numbers as quickly as physically possible,
49:19 then a language like C or C++ or even Fortran are languages which can do mathematical operations a bit quicker.
49:27 So from that perspective, Ruby is not the fastest language and that can sometimes cause problems.
49:35 But then generally what you end up doing and what GitHub does is if you have parts of your system that are very, very reliant on that performance.
49:42 And generally that will be five, one percent of a complex system will be really, really CPU bound and very reliant on high performance for the rest of the system to perform at a decent level.
49:56 Then you may end up just writing that in another language like C or Go or Rust or various other what we call systems programming languages.
50:05 So I would say that's my main problem with Ruby.
50:08 I guess another kind of niche thing is that because Ruby is a very, I mentioned earlier, a very flexible, a very dynamic language that allows you to write in lots of different ways.
50:17 It's also possible to write some Ruby, which is kind of incomprehensible because you can do all this really, really clever stuff.
50:26 And then you might feel very clever, but then it's when your co-workers come and look at your work in six months, a year or whatever,
50:32 they can't make head or tail of what you've done because you've tried to be too clever.
50:36 And that's a problem compared to languages like maybe Java, for example, which it's quite hard to write Java in such a way that it's really incomprehensible like that.
50:46 But then again, that's one of the things that makes, I think, Ruby a far more powerful language than Java is that it gives you the, you know, there's that danger,
50:53 but there's also the kind of the power there as well.
50:58 Thanks Mike for your answer.
51:00 So we have one from Yao who has asked, is there a lot of freelance work in Ruby on Rails?
51:07 Yeah, I think so.
51:09 I've not personally been a freelancer, but I have friends who are freelancers in the Ruby on Rails world and they seem to have not much problem getting work with Ruby on Rails work.
51:23 I think I would probably say it's in, you know, just to pull a number off the top of my head.
51:28 It's probably in the top five are probably programming based consulting gigs and freelance work that's around now,
51:35 because as I say, it's, it's a fairly widely used and established language at that point.
51:40 So often when you're doing freelancer consulting work, the client, even though they may not be writing the code,
51:47 they may have already decided the technologies they want to use because if they have other freelancers or if they have, you know,
51:54 employees that they're coming in at a later date, they want to kind of have something that is kind of going to be widely supported and not to user-teric.
52:02 So as a result, I think from a freelancer perspective, Ruby on Rails is definitely a good choice.
52:08 Great.
52:10 We have one from Antonio.
52:12 He's asked, "Is Ruby on Rails an appropriate platform for a small to mid-size business application
52:18 or is it better suited for larger corporate applications?"
52:22 I think it's well suited to both.
52:24 I think it probably is actually better for small applications.
52:28 So with Rails, GitHub is one of the reasons why we're probably one of the biggest sites that are using Ruby on Rails
52:35 Rails is because there were other sites that are far more popular than we are, like Twitter for example,
52:41 that initially started off using Ruby on Rails, but then as they've grown bigger, they moved more and more of their code away from Ruby on Rails
52:47 to other languages that they feel are more maintainable or scale better and perform better at kind of the very high volumes they have to deal with.
52:57 So from that perspective, I think Ruby on Rails is probably something that's more suited to kind of smaller applications,
53:03 smaller and medium-size applications than really, really enormous ones.
53:07 But then again, as I've said, it is used in some enormous applications as well.
53:11 Great, so we have time for one more question and this one is from Joshua again.
53:21 He asks, "Do you recommend that you work in a team for your first Ruby project?"
53:27 Yeah, I mean, I think working in a team in programming generally is pretty invaluable.
53:33 As I said, I've been working remote for a long time, so I've been remote for I think seven years now.
53:39 So working in a team does not necessarily mean working in the same room or the same building or whatever,
53:43 or even the same country as the other people you're working with.
53:46 But I definitely think you will learn more when you're working in a team with other people,
53:51 particularly if there's a mix of experience levels.
53:53 Whether you know more about Ruby than other people or less about Ruby,
53:57 and whether you have more experience or less experience in your industry or in software in general,
54:03 you will end up learning a lot more through working with a group of other people
54:07 who have different ideas, different perspectives.
54:09 And that's why, if you see what we did with GitHub earlier, we made that pull request.
54:14 One of the reasons we do that is because what's become more and more of a commonplace thing to do in software
54:21 is getting effectively someone else to check over your work whenever you do it.
54:25 And the reason for that is we're all working on, when you work in software, on complex systems,
54:30 and the complex systems have side effects that you may not have anticipated,
54:34 and we're all ultimately only humans, so humans make mistakes,
54:38 and it's good to have someone else to kind of help you, check you haven't made silly mistakes,
54:43 and also be able to teach you and for you to be able to teach them eventually as well.
54:48 Fantastic, thanks Mike. So that's all we have time for today.
54:54 We'll make sure we answer the rest of your questions in an email.
54:57 But I'm sure you guys will all agree that that was an absolutely fantastic insight
55:01 into not only what it's like to be a developer, but what it takes to get there.
55:05 And I hope you're all inspired to go and start taking steps to changing your career to tech,
55:10 if that's something you want to do.
55:12 Because you've joined us tonight, we'd like to give you guys something special.
55:15 We want to give you a web development short course for free.
55:19 We'll send this out to you, along with a copy of the webinar,
55:22 and some other great resources in the coming days, so keep an eye out on your emails.
55:26 And if you're really thinking about learning moving on rails and becoming a developer,
55:30 then here we do offer a course that promises to take you from beginner to job ready in six months,
55:36 with the job guarantee as well.
55:38 So we'll send all this information to you in a follow-up email.
55:42 So once again, I really want to thank Mike for joining us today.
55:46 We really appreciate you sharing your exciting experience with our community.
55:50 And thank you so much for everyone for tuning in.
55:52 Remember to keep an eye out for all those resources in your email.
55:55 They'll be coming to you very soon, along with your free short course.
55:58 And that's all from us.
56:00 Thanks again for joining us, guys.
56:01 And have a great day wherever you are.
56:03 Thanks.
56:04 Thank you.
56:05 Thank you.

Mike McQuaid

How To Become A Ruby Developer