The Rogues discuss threads from the Ruby Rogues Parley forum.

 

It’s going to be an interesting show today. [Laughter]

Random thoughts from the Ruby Rogues. Maybe we could call this episode ‘Deep Thoughts’. [Laughter]

We should call it ‘The Elephant’.

‘Deep Copy Thoughts’.

I’ll introduce myself as Jack Handey.

Hey everybody and welcome to episode 153 of the Ruby Rogues Podcast. This week on our panel, we have David Brady.

Whether or not we discover intelligent life there, I think we should consider Jupiter an enemy planet.

James Edward Gray.

I have no response to that.

That was a Jack Handey quote!

[Laughs].

Josh Susser.

[Chuckles] Good morning, I think.

I’m Charles Max Wood from DevChat.TV. And this week, we’re going to talk about some of the threads that we’ve had on Parley. There have been some pretty good ones over the last few months.

Hey, Chuck.

Yes.

What’s Parley?

Parley.

It’s the thing that the pirates have to agree to if they trap you in the closet and you ask for it.

Yeah.

Alright, okay. Or… [Chuckles]

Also known as, it’s our Discourse thingy. I couldn’t think of a word. I blanked.

It’s our private discussion community for fans and supporters of the podcast. JAMES: Yes, that.

CHUCK: Yeah

Thank you. Yeah, that.

The thing that I really love about using Discourse really quickly is not just that it’s so easy to use, but you can actually tell it to, in your profile, to do email list mode. So, people who want to consume it that way can, too.

Yeah. P.S., those are opt-in features. So, if you’re on Parley and you haven’t figured this out yet, we’ve heard some complaints that, “Discourse is not like the mailing list.” And that’s true if you have the default settings. But if you go in there and tweak your settings, you can make it pretty much like a mailing list. So, if you’re having trouble with that, please go in there and fiddle with your settings and choose to get the emails regularly. And you can treat it like a mailing list, which is great.

So, Parley has been chugging along for over a year now. And we have what, I don’t know how many members we have now. It’s over...

[Inaudible] look.

It’s over 1500, I think, the last time I checked.

It’s quite a few, yeah.

Yeah.

There are great threads on it all the time. I cannot keep up with all of it. It’s too much volume. I catch each thread and then I mark the ones I’m interested in and follow those. And yeah, it’s a lot of volume, which is a good thing.

Yeah, absolutely. And I really enjoy it. But there have been some terrific discussions on there. And we were talking through some of our favorites and decided to do the show on it. So, the official numbers on Parley are, we have 1329 people in the forum.

Woohoo!

825 topics. 7,687 posts, 4,427 likes, 1 flag [chuckles].

1 flag.

Which is one post that’s been flagged and not removed, I guess.

Don’t worry. It was an audible.

Yeah. 394 bookmarks, 1741 flagged, and 143,725 emails sent.

And 2 jerks.

Don’t talk about me that way.

But Dave and I try to keep in under control.

Yeah, yeah. [Laughter]

I have medication.

[Laughs] Okay, so we have a lot of stuff on Parley. And it had a bit of a lull when we switched over to Discourse. There was some mailing list nostalgia. But now that we have mailing list mode back, Parley has just super picked up in the last month or two. And it’s been a lot of fun lately. So, we have some great topics to discuss today.

Alright, so first off, here’s an easy pitch over home plate. It’s been discussed lightly on Parley, but also in some tangential ways. But Rails 4.1 is out. Has anybody used this at all?

Wait, what? I’m just kidding.

I heard there was nothing in it. [Laughter]

That’s because you heard that from me and I did not say that.

Oh, you were talking about the thread.

Yeah, the thread. The thread says, “Hey, there’s this stuff.”

For anybody listening to this show, Josh and I have had two hours of sleep between us.

And they’re sharing it.

Yes. [Laughter]

Because we’re single-threaded. [Laughs]

My life is multiple-threaded.

So, Rails 4.1 is out.

Yes. I’ve actually used it recently. So, I can talk about it a little bit if you want. I can tell you some of the things. But the thread on Parley is interesting. It actually points to just one specific aspect of Rails 4.1 and how to integrate that, and that’s Spring. So, for those who don’t know, one of the massive changes in Rails 4.1 is that most of the tasks like rails generate or rake db:migrate or stuff, every time you hit those tasks in the old one, it had to begin by loading the entire Rails stack. And so, there was, depending on your computer, typically a two to five-second pause while Rails booted up and loaded all of your gems and your environment and stuff. And in Rails 4.1, that’s largely been removed, thanks to the including of Spring. And the idea there is that the first time you do a task like that, spring spools up your Rails app as a background process. And that Rails app is wired in to watch your files just like Rails does in development environment, looking for changes. And so, when things change, that server kicks in and reloads that code using Rails reloading mechanism. And so basically, the server in the background stays up to date. And then when you do rake db:migrate or whatever, it’s just ready to go and happens in a snap.

Nice.

So, how does that compare to Zeus? That sounds like Zeus.

Yeah, it is. Similar things. They were competing ways to accomplish similar tasks. And for some reason, Spring is the one that got blessed and became officially part of Rails. But yes, I believe those are similar things.

Okay.

So, how does this compare to Spork?

Spork, am I wrong, but Spork focused on just the testing.

Yes.

Or am I wrong about that?

Yes, you are correct.

This is more holistic in that it focuses on even things like rake db:migrate and stuff, or rails generate, so to get rid of that pause throughout the system.

Right.

Yeah. And just for the show notes, I’m going to put the link that was shared in the Parley thread, because not all of our listeners are on Parley.

Right.

Yeah, and so this particular link is what if you’re using Rspec. Rspec’s external to Rails. Can it be made to work with this Spring system? And the answer is yes, very easily. Spring is very smart about all this stuff. And since now we use bin stubs in Rails, that’s the way you’re recommended to do your executables, you can just tell Spring to “springify” your bin stubs. And so, it’ll go through and it’ll be like, “Here, I’ll replace your Rake with something that’s Spring-aware. And I’ll replace your Rspec with something that’s Spring-aware.” And they use these background tasks and you have one for each environment. And then there’s a Spring executable that will show you what’s running and let you kill them if you need to for whatever reason. It’s pretty neat.

I’m used to using a rake in the fall, not the spring. [Laughter]

Different kind of rake.

Oh, okay.

This is a [inaudible] right here.

Okay.

Yeah.

I have a joke about hoes, but I’m not going to make it on the show, because we’re family-friendly.

Yeah, let’s leave that [inaudible]. [Laughter]

There is a gem called hoe. I’ll just say that.

Dave, just go for the [8:41 rototiller] joke.

[Chuckles] No, please no.

[Chuckles] Okay. So, other stuff about Rails 4.1. I like the Variants. Are people familiar with that? That you have, what’s it called, the system that lets us do all the templating, the Rails template engines? Variants. So, you know you can throw view templates in your view folder. I’m sorry, directory. And you can just chain a whole bunch of extensions onto it to say, “Okay. This is Haml and then it’s HTML.” So, you can control what the processing stuffs are through that pipeline.

Right.

And this lets you have a new kind of extension that you put on there that controls whether it’s for your browser or your iPhone or your other device. And I think that’s pretty cool. That makes managing another dimension in that space much more easy.

So, I have not used the Variants feature. And to be fair, I think it’s actually been a little more fancy than Josh said. I think that’s the typical use case, is detecting different platforms and stuff. But in truth, I think you can actually make Variants for any arbitrary restriction you decide, right?

Yeah.

Yeah, they generalized the system.

I have a really good idea for Variants. James, what’s your IP address?

So seriously, are Variants good for the administrator’s logged in versus a guest is logged in?

Yes. I believe you could actually use them for something like that.

Yeah. So, it looks like it keys off of the request. So, any information you can pull from the request then, you can use. So, the user agent includes iPad for example, but you could also do by IP address or something else.

Right. You’re basically taking a before filter and you could figure out something even using the database or whatever. And then you could turn on which variant this request is, basically.

Nice.

Yeah, [inaudible] it’ll do is just create some Rack middleware to annotate the request with some extra data.

That said, so this is interesting and I’m holding judgment. And I confess I have not used it yet. But the actual use case of designing different for mobile apps versus desktop that the Rails team [side] did, I was a little skeptical on that, when it feels to me like we’ve been moving away from that with responsive design and stuff like that.

I was actually going to say that. I was going to say, “Please use responsive design.”

So, responsive design is great, but then there’s how do you change the interaction? Because things are different enough that just your CSS and HTML is only going to get you partway.

You may be right. It will be interesting to see how this feature plays out.

Yeah.

I agree. What I hope it doesn’t become is the 16 pages I have to edit for this one action.

[Laughs] No kidding, right?

That’s what I hope it doesn’t become. JOSH: Right.

Yeah.

But there are some other features I have not played with. I don’t know if you all have. But there’s a database enums, which are these list of values that you allow, like in a status column for example. And Rails will manage converting those to integers and converting them back. So, that’s quasiinteresting, but I haven’t played with it yet.

Right. I want that to be tied to the PostgreSQL enum.

Yeah.

Yeah.

That’s my feeling on it, too. It’s very database agnostic, so it’s just an integer behind the scenes and not really intelligent. I would have liked to see a deeper tie-in with Postgres as well. DAVID:

Yeah.

Oh, yeah, plugin coming soon.

Yeah, hope so. And then this new one, again I’ve not had a chance to use this but I’m super excited about it, Mailer previews.

Yes.

If you have emails and you make HTML emails, it’s easy to set it up now where in development you can just hit a URL and see the current version of that email. So, super cool there. And then the other feature that, actually one of the reasons I wanted to talk about Rails 4.1 is on Parley one big topic we have been discussing a lot is 12 Factor systems. And that includes many things. And we’ll probably get into all of those eventually. But one of the things is how do you get configuration type information into your application. And typically on something like Heroku, that takes the form of environment variables where you set your database URL and that’s how it’s going to connect up to it, or a URL for where Redis is, or things like that. Rails is moving in that direction. It does now have good support for database URL. And one of the new files added is this secrets.yml file. And it allows you to configure these bits that you need to pass into Rails like that, these configuration bits, in this one YAML file. But the YAML file is, like most YAML files in Rails, it’s ERB parsed when it parses it. So, you can set environment variables and read them in there, in the YAML file, and build them up that way. And you can have different configurations for development, test, production, et cetera, as you always do. I just thought it was neat to see Rails making this easier. And then inside your app you have a nice interface Rails.application.secrets. And that’s where you can pull that information back out and use it. So, it’s a small change but it seems like a good thing, pushing in the way apps have been going.

So, what are the issues with doing that, James?

Like downsides, or what do you mean?

Yeah. Well, so there is a separate thread that we ended up talking about what we were going to discuss today, the 12 Factor Apps one.

Right.

The discussion that we had on Parley about this was there are some downsides to managing things using environment variables. And what happens to the security of that information on your system. One of the things that were brought up was some of the exception reporting tools can include a dump of the environment that the Rails app is running.

Right.

And that can leak the secrets to your exception handling system, which now has maybe your secret key for talking to something. And then it reports that to you in an email that’s just sent out over an insecure thing.

Yeah, that’s a great point.

Or something like protected health information when you’re trying to follow HIPAA guidelines.

[Chuckles] Yeah, yeah.

That could be a problem.

Right. So, the subtleties around managing a Unix environment and in setting environment variables, I don’t even get that stuff and I’ve been using Unix since the 80s. So, it’s not entirely clear to me how that stuff works in all details. And yeah, so one of the things that I didn’t realize is that when you send a signal to, say a Unicorn process to tell it, “Oh, you want to restart,” it doesn’t get a new set of environment variables. It just restarts stuff within the process. So, if you’ve gone and filled it around with your environment settings as part of some deploy script and then you go restart the Unicorn process, it’s not going to get those new configuration settings.

Right. So, environment variables like most things in Unix, it’s like standard out, standard in, and stuff like that. They’re handled at the time the process is forked off. And they inherit the environment from their parent. So, the way you change things in Unix is you do some fiddling in the parent process then you fork a child and it has the new environment. So, what Josh points to is exactly right. If you just do something like a clean restart where, in Unicorn I think what it does is it forks a new master process, but because that master process was forked from that parent it will inherit that parent’s environment. And if you made changes to it, then you’re going to have to have some way of updating them and getting that through. In defense of secrets.yml, this is a new system and you don’t have to do it through environment variables, just to be totally clear if I wasn’t. If you would rather just have that in some config file or whatever, you don’t have to use ERB parsing and you can put the data right in there. So, it’s flexible I think. But your points about environment variables are duly noted, yeah.

The thing that I loved about that conversation is how many different ways people approach the problem of managing the secrets that need to be distributed among your servers so that they can operate, and how you get those secrets from somewhere onto those boxes and where they live. And I love the conversation about, “Oh just put stuff in files, because it’s easy to manage that.” It’s easy to audit that. It’s a very stable way of doing that and very understandable.

And that works here, too. Rails is just giving you the official file where that stuff should live.

Right. But the whole how you manage getting the file on there and keeping those secrets out of, say a repo…

Version control?

Yeah, yeah, not letting your secrets accidentally get committed to Git and then published on GitHub, right?

Yeah.

Right.

By the way, if you mess up your GitHub repo and commit some secrets to it, there is a Git trick for getting rid of that. What is the Git for that? It’s git something branch, git filter branch, yes. Yeah, so if you look on GitHub, they have a little tutorial for how to use git filter branch to remove accidentally committed secrets from the history of your repo.

Right. It’s not enough to just go in and take that secret back out and push a commit because it’s in the history, so we can find it. So, you have to go back and edit the history, basically, to remove that bit of back data.

Yes. So, one of the approaches I’ve used that I think someone mentioned on there is basically you keep the secrets.yml file or whatever other files you’re putting your sensitive data in, keep that in a separate location from your main app repo. And part of your deployment might be going out and refreshing that info from a different repo.

Yeah.

So, you can do a same sort of install from a different repo. You can have it managed in some private gem that you get from your own private gem server. There are several ways to get it on there.

Yup.

Right. Yeah, it’s an interesting discussion.

I have used that style in the past. And it always seemed odd to me that if I can get to one Git repo, why can’t I get to the other? But then when you actually see it in production, the secrets files are in the repo that only the ops guys can get to, only the deployment team is allowed to get to that repo.

It’s on a different server, et cetera.

Yeah. Git repo doesn’t have to mean it lives on GitHub.

Right, yup.

It could mean it’s in your own private Git server or whatever.

Well, I’ve also seen those files are synced or just scp’d.

Yeah, copied [inaudible].

You could script it ten different ways and make it work.

Here is our file, or our app. Here is the one secrets file you’ll need to engage everything. Exactly.

And it’s on a 3 and a half-inch floppy. [Laughter]

We’ve dispatched the driver. He should be there tomorrow. [Chuckles]

Yeah.

He will make the drop at an anonymous trash can. [Laughter]

Right.

Okay, so I think we’ve done that one to death.

Yeah, it was just good. I think, so I will say that Rails 4.1 was a pretty smooth upgrade. I did it on an app I have right now and it was pretty smooth. I didn’t run into many problems. They did change one tiny thing in Active Record Relation that I think if you’re going to run into bugs, this is probably pretty likely. Relation used to just duck type as an array pretty heavily. And now, they have removed all destructive methods from it. So, if you’ve ever done something like done some query and then done a shift or something like that to pull entries off the front or things like that, delete or whatever, any of the destructive methods, those are gone now. So, I had one minor error in an app from that. But once I fixed that, it’s a pretty smooth upgrade. And I will say that the Spring thing, I was skeptical and I hadn’t really looked into it much. But it’s been great. I really like it.

Cool. Since we’re switching gears, one of my favorite threads and one that I actually have about three blog posts related to that I’m going to write is that where are all the Junior Developer roles for jobs?

This is a great post, yeah.

And I thought and thought. And I kind of got mad for a little while. [Laughter]

No. Why did you get mad?

Well, because it really felt like some of the folks out there who either don’t feel like they’re senior developers or really don’t have the skillset to be a senior developer yet didn’t really know where to go to find jobs. And the people out there all seem to be looking for senior devs. Most the places I’ve talked to about, “Hey, I’ve got this guy I know that’s looking for a job,” yeah they’re like, “Well, we’re looking for senior people.”

Yeah, I think that’s true. We’ve touched on this right, that all the job applications are rock star ninja wizard whatever. Where’s the room for the coder, the junior dev?

Our next episode should be the wizard’s duel on Ruby Rogues.

Yeah [chuckles]. So, I don’t like to publicly harsh on recruiters too much, but I do think that there’s a bit of, what do they call it, exposure bias. What we see in terms of the jobs that are promoted are the jobs that are going to make a recruiter the most amount of money.

That is a good point.

So, the jobs that they promote and send out in their emails and all that, are the ones that are looking for the rock star ninja guru programmers that can get them a big commission. So, that’s the ones that they focus on. I think there are actually plenty of junior jobs out there. They’re just not in the same places. My first job out of college programming was at Xerox. It was a company of over 100,000 people. And I think that a big company, it’s not going to be the super startup experience and you’re probably not going to get to work on a great agile team, that kind of stuff. But it’s a great first job. And I think that everybody should work at a big company at some point so that you understand how crazy it is to work at a big company and go off and [inaudible]. [Laughter]

I am not kidding about that. I think that it’s really great training because big companies, they need a working process for them to work at all. And there’s a lot more process there. So, you get to see and experience the necessary processes with much more focus and attention on them. And then when you go to a smaller, more sane company, you’ve absorbed a lot of the process orientation.

And then that becomes easier and it’s not such a big deal in your small company.

Right.

But for junior developers, I think that’s a great place to start. Go work at Oracle or Apple or IBM. Those are great places to start your career. That’s what I did. It doesn’t have to be some little garage shop startup.

So, Katrina had an interesting post on this thread. She mentioned that terms like junior developer are very vague. And what does that exactly mean? And when do you transition from one to the other? She said she was thinking of a field where in her opinion, the apprenticeship usually lasts about ten years. There are still industries like that. And whereas in programming, you can go to all these schools, these coder schools, and be at what level in six months. Are you still junior at that point? Have you made it to medium developer? What does that person even call it? I don’t know.

I’m interested in everyone’s thoughts on this.

So, one thing that’s related to this is, and I can speak to this in the sense of a codebase, so I’m working with the same client that James is working with. And I came in at a point where they really didn’t have work for me because I wasn’t familiar with their codebase. So, in that sense, I’m kind of a junior guy in the sense that I’m junior to the codebase, not necessarily junior to the technology. And so, I’m getting in there and I’m writing different components that all look very similar to each other as part of the application. And what this does is it orients me to the way that the overall system works because eventually, these are all going to plug up into something else. And so, it works the same with technologies where you get in and you figure out how people do things and you learn that way. And so, there are plenty of jobs out there where people need that kind of help, where you have enough proficiency to do the lower level stuff, or the higher level stuff depending on how you orient that, and then eventually your can grow into the more complex pieces of things and make them work.

Yeah.

And I think companies that don’t look for people like that are being very shortsighted because you can actually train people before they get the habits that we all grow into. You can make those habits the habits that you want them to have and do things the way that you want them to do things. But the other thing is, you can bring them in and really just make them into experts in your codebase.

That’s a good point. There’s a username Daniel who commented in the Parley thread and said, and I’m just going to quote him directly. He said, “Okay, I’ll come out and say it. There’s a common perception that you invest resources into a junior dev and once he becomes better, he’ll move on to another company.” And I wanted to throw that out there. I agree that that’s a perception that I have seen, but I’ve also seen a perception of like Chuck was talking about, of cultivating, where you bring somebody in and they’re hungry. And there are two things that you can hire for: you can hire for expertise and you can hire for hunger. And as long as they can think, you’re going to get a good developer, right? Maybe they have to figure things out from first principles or maybe they figure it out because they’ve forgotten seven ways to do it. That’s the difference between a good junior and a good senior. And if your company has a way of consistently giving hungry engineers enough to work on and enough to grow into, the only reason they would move on is because they have become so much more valuable than you are paying them for. And you need to address that. You need to come back to them in a year or two and say, “Okay, well guess what? You’re now a Rails developer with two years of experience and we want to reward you and give you the title of senior and give you a pay hike, because we want to keep you.” And now you get to keep somebody who’s got the lore of the project, all the processes and all the weird stuff, and all the habits that you’ve carefully inculcated. But you’ve incubated them and then you’ve kept them. You basically say, “Okay, now it’s time for you to step up.” It is certainly true, I think it’s a misconception in the Ruby, I think if you have the perception that you can hire somebody at a junior wage and keep them there for five years, I think you’re going to be disappointed in your hiring and employment process. [Chuckles]

Yeah.

What was the Dilbert-ism around that? The pointy haired boss says, “Our HR department says that we’re only going to pay market average salaries but we want to hire the top talent.”

[Laughs] Yes.

And Dilbert says, “Okay. So, you want these idiot savants who are…”

Occupational savants.

Yes, yeah. “Occupational savants who are great at their job but too stupid to understand we’re underpaying them.” [Laughter]

So, I love that quote. So, if you’ll forgive me Josh, I’ll…

Please correct it.

I’ll cite the exact quote, which is, “So, we’re looking for occupational savants, which is a person who is a brilliant engineer yet somehow unable to compare two salary figures and determine which is the larger.” [Laughter]

Yes.

Well, that’s exactly the thing, is I think we all want certain things out of our jobs. And I think as people mature as programmers, they get to the point where they want certain things out of their jobs. And I think for the most part, it boils down to they want something that’s fulfilling. They want something that’s interesting. Fulfilling is usually, I’m making a difference one way or the other. And then it has to pay enough. And you can provide the first two, but as soon as somebody comes along and gives them a high enough number that’s significantly enough higher than what you’re paying them, they’re going to look at those two numbers and they’re going to have to weigh out what the advantages are of staying. And so, if people are leaving it’s your fault for not being proactive in making sure they don’t have any reason to even look.

Yeah.

Yeah. I do remember the glory days of the dot-com boom when people, developers were getting ‘salary raise reviews’, basically their annual review and promotion, every three to six months. Because if the employer wasn’t upping their salary regularly, they would just move to a new job and get a 20% raise.

Yup.

Right.

Better somewhere else.

And so, people were changing jobs two or three times a year and doubling their salaries over the course of a year or two. It was just nuts. [Chuckles]

Yeah.

One of the things is, too, I think people underestimate how helpful and productive junior developers can be. And it doesn’t even have to be, I think a lot of people have this mindset where the junior developer is the one where you construct everything they do and they take care of it. It’s like you lay out the steps: do this, do this, do this. But we have interns where I work and they’re great and very helpful and self-task-assigning and things like that. We give them their autonomy and they do great with it. We had a search system that was problematic in that we needed to be able to set priorities for which results were returned from the search system. It was supposed to work that way and for some reason we could not get it to honor the priority field in our particular case. But we did use the system where it learned from people’s choices. So, if someone picked this 100 times, then that one would be promoted over something that had been picked 5 times. So, when we couldn’t get the priority system working, we had a junior developer come in and was like, “Oh we can solve this problem,” and just wrote a script that grabbed the priority count and hit the select URL…

Clicked it 100 times?

That many times, yeah.

That’s awesome.

…and was like, “There you go. Priorities.”

Yeah, I want to say a little bit about the value of junior developers on the team, too. This was my first contribution to the thread on Parley. It’s not just about how awesome your senior developers are. The team working as a team requires a certain balance.

Yeah.

And you don’t want to have everybody be a general. You need some soldiers as well, and some lieutenants. Otherwise, who’s going to go out and dig the trenches and whatever? And there are some things, like junior developer doesn’t necessarily mean bad or inferior developer. It’s somebody with less experience and seasoning. But the upside of that is that junior developers, they haven’t been exposed to all the same years and years of crap that senior developers have had to go through. So, when they see a problem, they bring a fresh perspective, which is both the power of the beginner mind, so they don’t have the same constraints on their thinking, but also they find problems that a senior developer would find boring (Oh, I’ve done this a thousand times), they find those problems interesting. That means they’re going to put more attention on it. And they’re probably going to do a better job.

Yeah.

So, we find on a team that it’s great. There are some things you want the junior developers working on because they’re actually going to do a great job on it.

And other things related to that is that a lot of times they will come up with solutions that the senior developer dismissed out of hand, that will work. Because our experience as senior developers say, “Well, the right way to do this is somewhere over here,” and they’ll go experiment somewhere else and find something that works really nicely.

Sometimes they’ll bring, this is a personal anecdote but I’ll keep it very short. Sometimes juniors bring something completely bizarre and unexpected to the table that the seniors, we don’t go to that sector of the solution space because we totally could but we just don’t have the ability to function there. We’ve never had the ability to function there so we just don’t even consider it. And a junior comes in and they just happen to be thinking about that. To the beginning mind, all things are possible. So, they’re considering this impossible solution space. And the biggest example I can think of this is I was working with a developer who’s 12 years my senior. It was a fantastic opportunity to work with him. And I watched him just disintegrate physically, emotionally, and mentally over the course of the day. It was about four o’clock in the afternoon. And he was growling, he was cussing this computer, and this was very uncharacteristic from him. And he looked at me and he said, “Dave, I don’t understand. This computer just won’t work the way I expect it to.” And I looked at him and this was something that I was focusing on about personal brain power and effectiveness and that sort of thing. I looked at him and I just said the first thing that came to my mind, which was, “Have you eaten?”

And he looked at me and he blinked a couple of times and he said, “No. Let’s stop and go get a hamburger right now.” And we went and we got a hamburger. And we came back and his computer magically sorted itself out once his blood sugar was… [Laughter]

But that was something that he never in a million years would have considered, because it wasn’t a computer problem. And because I was coming from this weird space of blood sugar and brain function, I was like, “Here, take this.” And juniors do that.

Yeah.

Well, diversity does that.

Yeah. And that’s I think the point of this. There are so many cases where diversity, brains, things just always adds ideas, right?

Yes.

And it’s so valuable. And it’s true in senior, junior, everything.

There’s also one other subtle variation on that, and that’s that if you have a team that’s all senior people, senior people have overtime, we all have these strong opinions about how things should work on the team. And so, we all bring a certain philosophical outlook to the team dynamics and we’re used to working certain ways. So, you can build a team around a couple of senior people who have compatible philosophies and then grow the team with some mid-level and junior developers. And then you culturally indoctrinate them in that philosophical orientation to development. And if you have a team that’s all senior people, the odds of them having compatible philosophies there are much lower. And so, you end up with this team where everybody’s fighting about how to work together. Whereas if you have a team with a couple of senior people, then it’s easier for the team to gel around a smaller number of those opinions.

Right.

And the other thing I would stress is if you do have a healthy senior/junior mix, then plan on that and make sure education and stuff are part of what you’re doing.

Yeah.

Yeah, mentoring.

Yeah, exactly. You need to be facilitating. You need to be growing these employees and like Chuck said, you need to recognize when they pass points when they’re no longer in those lower rungs. You need to treat them and pay them accordingly at that time. And make sure that you’re monitoring that stuff. Don’t just put this group of people down in a category and be like, “Oh, those are the people that do the grunt work,” or whatever. That’s not healthy or valuable.

I like tools like Tracker that basically are very egalitarian. It’s just a list of tasks that you have to get done. And the team, you can have a junior looking over that task list. Yeah, the first habit you give them is figure out what corner of the universe you can wrestle to the ground and then go wrestle it to the ground. And if they’re looking over everything that’s in the current sprint and it’s all too big for them, that’s when they go stand up say, “I’d like to help, but everything’s too big. So, I’m going to volunteer to tackle this, but I need a senior to help me.” And that’s a great example of hungry versus experienced, where there’s a junior who’s looking at the task list and she’s overwhelmed by everything that’s in it but she’s willing to step up in standup meeting and say, “I want to tackle something and I need the right tool for tackling this, is a senior engineer. So, who wants to help me tackle? I’m interested in learning this. Who wants to help me learn it?” And if I was a senior engineer on that team, I would be jumping at the chance to work with somebody who’s hungry.

Exactly. They’re the people that are going to be receptive to the things you show them. And yeah, I think you’re right. I think that’s such a healthy thing. And I love what you said about Tracker. I’ve never even thought of it that way, that it doesn’t discriminate. And you can look through it and you could be like, “Oh, well I can handle that.” And I know personally, I even think that sometimes I’m often wrong. But it doesn’t matter. By then, I’m neck-deep in it and I’ll figure it out.

Yeah. And whoever put the task in Tracker, gave it one point because it was going to take a senior engineer an hour to do it and it ends up taking a day and a half. And guess what? Tracker’s philosophy compensates for that. And it all comes out in the wash.

Yeah. But the next time you have to touch something like that, you’ve got a junior dev or another dev that can jump in and handle something similar.

Yes. And I’ve seen that.

Is more familiar with the system, yeah.

I’ve seen so-called juniors turn to other juniors and say, “I just worked on that. I can show you that.” And that’s win-win.

So, one other thing I want to bring up with this, because I’ve talked to several junior developers that have expressed this feeling, and then I see them email the users group lists or they show up and they say something like, “Well, I’m just a junior developer. And I’ve only been programming for three months,” blah, blah, blah, blah. And I just want to go over there and shake them. It’s like, “Look. You’ve decided that you want to do this for a living. And the way you figured that out is you sat down and you delivered code, okay? And so, it’s okay for you to be confident in the skills you have. Sure, they don’t compare to senior dude over there. But go apply for the jobs. Go out on a limb.” I feel this relates very directly to our Impostor Syndrome episode. But I really just, it just makes me so angry because it’s like, you have skills. You have skills that people need. And it doesn’t matter if you’ve been programming for three months or three years and you consider yourself a junior developer. Go out and talk to people. Go out and apply for those jobs. Find out what they’re looking for. Build those skills. Keep writing code. It’s not impossible. There’s a job out there for you, so go do it.

That is awesome. I just loved how excited you got about that, Chuck. [Laughter]

I just want to shake people. [Inaudible]

I’m with you, man. I’m with you.

Well, I’m sorry. It’s just the way I feel.

Yeah.

I really do get passionate about it, because it doesn’t matter how long you’ve been doing it. And this is something straight out of the letter to a new developer that Avdi picked last week that Brandon Hays wrote where some of these guys, they have ten years of experience but it’s all the same year experience repeated ten times. [Laughter]

Yeah, I can type rails new really well.

Yeah. And so, honestly it really just comes down to, are you junior or senior? It doesn’t matter. What matters is that you can go and you can deliver some value for an employer. And if you can get in and get the interview and talk to them and they feel like you’re the kind of person that they want on their team, it’s not going to matter that you only have three months or a year or whatever under your belt. They’re going to talk to you and they’ll get a feel that, “Hey, this guy or this girl, this person really can deliver for us and we want them on our team.” And then they’ll bring you up to what they need.

And if you’re vastly junior, an experienced hiring manager is going to suss you out really quick and figure out where you’re going to be able to contribute. And if they need you, they’ll hire you.

Yeah.

So yeah, a good mantra is, “Somebody out there right now needs your help today.” And if you focus on finding that person, all of your fears about, “Who will hire me?” just go way, because now you’re looking to find the person that you can help.

Yeah.

Alright. As much as we have said lots of great things about this… [Chuckles]

There’s even a bigger controversial topic on Parley that we want to get to. So, I’m going to swing the conversation that way. The thread was basically should I use Sinatra or Rails? Go.

Sinatra.

Neither.

Merb. [Laughter]

We’re done. Let’s do some picks.

Yup. [Laughter]

I love this question.

My answer is yes. I’ve used Sinatra. I’ve used Padrino. I’ve used Rails. And I’ve written pure Ruby web services. With the exception of Padrino, I’ve used the other three in the same project.

I’ve written straight Rack.

So, I really want to flip this one around on you, if I can a little. A lot of people seem to have, in the Ruby community, experienced Rails devs and stuff I feel like sometimes have an aversion to going to Rails and would like to resist it if they can. So, maybe a better first question is why not use Rails?

Right.

Am I wrong in thinking that?

No.

Sometimes I feel like I see people use Sinatra because they feel like they should rebel against Rails.

Yes.

And it’s like, “Congratulations. Full marks on your punk rock face.” But at the same time… [Laughter]

That’s so right. Oh my gosh.

Punk rock star.

Chuck and I worked on a team two or three years ago, a couple of years ago, that the IT team was all Java. And they were afraid of Ruby. And they were afraid of pop culture and Ruby’s more pop culture than Java. And Rails is the poster child for pop culture in Ruby. And there was a lot of FUD, fear, uncertainty, and doubt, surrounding Ruby. And even more surrounding Rails. And so, in order to not violate this weird political thing – okay, all political dynamics are generally weird but this one was extremely weird – we had to stay away from Rails. And we were building this Sinatra app and we ended up including Active Record. We ended up including Action View, Active Support, Action Mailer. And at one point, one of our developers went through the gem list and said, there’s one, something either like migrations or maybe it was Action Mailer, but one of the engineers came back and said, “You know, we are missing two gems. And if we include this support gem, then the only other gem we are missing is the one that’s actually called rails.” [Laughter]

And that I think is the anti-pattern. If you think, “Oh I’m going to Sinatra because I want to do things my way,” and blah, blah, blah, and then the first thing you do is write a router and then the second thing you do is come up with some kind of controller system or stuff like that. And I say this fully being the guy that’s done that more than once.

Yes.

I think we’ve all done that.

So, if you were there and you did all that, then you’re rebelling against Rails for the wrong reasons.

Right.

Yeah.

You should probably go use Rails and let that be good. So, I’d like us to start with that.

James, I think there’s a little context that I want to insert here.

Go for it.

And that’s that there’s a metamorphosis that happens in the development of an application. You start with a framework. At the beginning of your application, when you type rails new, 100% of the code in your application is Rails. It’s the framework code. And then as you work on your application, the ratio shifts. Soon, 10% of your application is the application and 90% is the Rails framework. As you grow over time, the amount of code in your application dominates. It ends up being bigger than the Rails framework, or the part of the Rails framework that you’re actually using. And at that point, the framework starts to become constrictive rather than enabling. And you’re now making decisions about, “Okay, how do I follow the framework’s rules?” At that point, you have now outgrown the framework.

Let me say something to that, because I had a good conversation about it recently.

Cool, definitely.

Talking to people about their presentation for upcoming RailsConf. And that’s I think Rails gives you a lot of onboarding things. We’re going to go with these conventions. We’re going to just think this through for you so you don’t have to worry about it and stuff like that. And then what we were talking about on this conversation is we were like, once you’re into medium and large app territory, what is Rails deciding for you then? And the answer is nothing. At that point, you need to be making the choices. You’re going to have to decide how am I going to keep this under control, which strategies am I going to use, et cetera. And that I think is where what you’re talking about Josh, depending on how you make those choices, you may actually run into a wall based on some of those early choices that Rails helped you past.

Yes. That was very clear description of that.

Yeah. So, I think that’s true. And so, Sinatra, the difference there is Sinatra doesn’t really put those walls up. You won’t run into that. But also, what you won’t get is all of that onboarding and early decision-making that does put you through small and on into medium apps. And you will be the person making all those decisions from the get go.

Yeah.

Right. So, there’s also the Sinatra versus Rails thing, is the concept of curation. And if you’re starting out in the Ruby-based web app world, Rails is probably the only choice you want to make, because it’s this very nice set, nicely curated, selected set of compatible features.

Yeah.

We have an object mapping system.

But [inaudible] turbolinks. [Laughter]

I wasn’t going to mention it.

Sorry, I think we did.

But you have all the different, you have the M, the V, and the C. And they all integrate nicely. And it’s just a very cohesive way to get started. And you don’t have to spend all of your brainpower making all of these choices about how to assemble your foundation for your application. That is great. And if you have leveled up a few times and you’ve built ten different web applications and you have all of your own personal preferences, you can assemble those components yourself. But I wouldn’t do that as someone who is just building my first or second Rails application.

Right. And also, I’m not even sure you should do that. I’m not even sure you should do that at the beginning of a new project, assemble all the components yourself, unless you know you’re building a very specific structure that’s pretty far afield from a typical web setup and stuff. Nine times out of ten, that really complicated part is one small section of your Rails app that you would…

Yeah.

[Laughs] It’s 2% of the code.

Right, that you would break up. And then if you made the decision based on that, then the other 98% you had to completely design for no benefit. That, I think is something to wary of. That said, I am very pro-Sinatra and use it a lot. And I think we should talk about some of the things about that, because I see it more and more. And there are a lot of advantages to it.

Before we do that, can I suggest a heuristic and have you guys either vet it or kick it, which is that it sounds like a consensus that we’re coming towards is we recommend that you know Rails and as you look at other frameworks, you should understand them in terms of what they give you over or under Rails, as tradeoffs against Rails? Is that fair?

Yeah. I think that really helps, yes.

Sounds good. So, tell us about Sinatra, James.

I will say that I think there are some big benefits to going with Sinatra. And there can be times when it’s a really great fit and things like that. One of the first hurdles though, I think you’ll run into with Sinatra, is that you don’t really have Rails making those decisions for you. So, you generally start with, “Oh now I need a router,” or something like that. I need a way to associate with this so I don’t end up with one gigantic 1000-line Sinatra file where it’s get this, post that, get this, post that. And there are patterns for building bigger Sinatra apps. So, just the simplest one of all probably is Sinatra sits on top of Rack, which I think we all know. Rack includes a really simple Builder. And the builder in Rack basically lets you map some prefix to a given Rack app and the Sinatra app is a Rack app. So, just by using that, you could say, posts go to this Sinatra app and comments go to this Sinatra app. And just in that one thing, a super simple change, I’ll link to the documentation of Rack Builder, the example off the top of the page shows it well, and just in that one simple change, you almost have controllers from a Rails-esque point of view. So, you can manage bigger Sinatra apps, but you probably need to start thinking about that pretty right off the bat.

Yeah.

So, one of the things I’ve seen is people extract a section of a Rails app, like a controller, and they’ll pull that out as a Sinatra service.

Yes. I’ve definitely seen that too.

So, what I’m not clear on is, what are the characteristics of that part of your Rails app that would lead you to pull that out and make a Sinatra service?

There are lots of different reasons I think to do that. One is if the overhead of Rails has become significant in the request, like due to volume or something like that, but you’re not using very many Rails-isms – probably a good example these days is you’re just feeding a very simple JSON API or something for some wizardry that happens in the frontend – if Rails has become a significant hurdle at that point because of the overhead, then dropping to Sinatra can make it go much faster. It can also allow you to do things like if you have your main Rails app and your Sinatra app that’s fronting your API or something, then those two can be deployed/restarted independently of each other, if you’ve split them apart.

Okay.

I think those are good reasons.

So, how would you compare doing that as a Sinatra app to using the subset Rails API configuration? Do we want to mention what that is?

Yeah, so you’re talking about things like Metal, right?

Well, there’s Metal which is an interface to Rack middleware that’s pretty low-level inside Rails. There’s also, speaking about curated sets of components, there is a stripped down version of Rails that’s intended to only be used for serving an API. It’s not intended to be a UI-based web application.

Yeah, I thought that was Metal. So, I don’t think I’m totally clear on the differences there. I would definitely say that could work, that using trimmed down Rails and stuff can work. And maybe it’s just a matter of, how much bang for your buck are you getting? Rails is everything and the kitchen sink. So, part of that is, think about just Action Pack alone. All the stuff that happens in a controller and the crazy rendering with ERB and all the various XML and builder and variants we just discussed, all this innate rendering logic, if you’re calling back to JSON all of that’s wasted on you.

[Chuckles] Great, it’s nice. You have it. But all of that machinery isn’t doing anything for you.

On the other hand, you do get things like the caching layer integration.

That’s true.

There’s a lot of stuff about dealing with session management, security, authorization, protection against security exploits.

I would say the security reason is probably one of the more compelling advantages of going with Rails and something like the session management. If we’re talking about APIs, they often have very simplified versions of that and may or may not use a traditional Rails session. But I think you’re right about Rails is pretty good about keeping up with common security exploits, taking just the bare minimum of steps to protect you against really stupid mistakes, et cetera.

Yehuda Katz had a blog post a while back about why Rails is a really great choice for just being an API server. Let me go find that.

Yeah, I think that’s a good point. And there’s no right way to do it. Then again, I will stress again that having them as a separate process sometimes has a lot of advantages. And you can obviously do that in Rails. But this is another point. At some jobs you have a lot of pieces and may be running on a lot of instances. So, if you’re running 120 instances, let’s say, virtual instances, and you’re running 120 Sinatra applications versus 120 Rails applications, the server profile you need is dramatically different. Dramatically. Sinatra is nothing. It takes up so little space. Rails is a monster. When it fires up, it needs a significant chunk of resources. So, if you’re going to run a whole, whole bunch of those then you’re going to be buying some bigger servers. That’s just the way it is.

Yeah. one other thing I want to point out related to the larger stack that you have with Rails is that a lot of times, it makes it a little harder to figure out what’s going on. And then this is one of the rules that I use to at least think about Sinatra, is when I say, “Well I just want it to X.” And so, I have this real simple stack. I don’t have all of the concerns that we’re talking about here, not Rails concerns, just general concerns over the application. I’m not as worried about the security for whatever reason. I’m not as worried about caching. Or maybe I can stick that in somewhere later. Then I at least think about using Sinatra. And then if one of those other things really rears up and says, “No, you’re really going to need this,” then I have to think about, “Okay, do I need to put this in Rails, then?” The other rule I tend to use is if one of the major pieces of Rails is something I’m not going to use, say database. Or if the view structure I need is really, really simple and I can just bolt Active Record onto Sinatra, a lot of times I consider that as well, just because it just gives you that smaller stack. And then I am only concerned with the things that I’m concerned with. And the rest of the extra stuff that Rails gives you isn’t there.

Yeah. I do think we’ve highlighted a lot of interesting decisions here. Josh has a great point. There’s a lot of times when even for APIs and such, Rails is a great fit. One of the things I would also want to mention because I think some people don’t know this is Rails Router can route to any Rack application including a Sinatra app. So, if you have your Rails app and you have a separate Sinatra app for whatever reason and you want to just fire them all up together, that’s fine. You can do a Rails route, put the URL in, and list your Sinatra app right there and it will go straight to it. So, you can include Sinatra apps inside of Rails and it works fine.

Yes.

Is there a good guide or tutorial for doing that? I know it’s really simple, but just [inaudible] to show you.

That’s a good question. I don’t know. I’ll google it and see if I find a good link.

Alright. Anything else on that? Or any other things that we should cover before we wrap up the show?

One other thing I will say in favor of Sinatra is that it does encourage me to experiment a little more. For this particular app, this little chunk, let’s try Sequel instead of Active Record. And if you don’t know about Sequel, you really ought to do that sometime. You ought to try it instead of Active Record. I’m not as big a fan of Sequel’s model interface, so the part of it that tries to pretend that it’s Active Record. For that, I would rather just use Active Record. But the interesting thing about Sequel, Avdi had a great Ruby Tapas on it a while back about how it’s a more modern DBI, if you remember Ruby’s old DBI database interface. It can allow doing these neat queries and stuff in a really elegant syntax and in a very performance efficient way. When your problem doesn’t particularly map to an Active Record style ORM and you can do it with a few nice Sequel queries and stuff, Sequel can be nice to play with. And I realize you can use Sequel with Rails and you can drop out the Active Record components and all of that. But I just find I’m more apt to do that kind of stuff with Sinatra because [inaudible].

Yeah, I think that’s great. And especially if you’re doing ETL kind of processing, extract, transform, load, streaming, transforming data from one location to another. And Active Record, one of the things that you learn eventually working with Active Record, is when you do a find and pull a model in from the database and create the Ruby object for that, there are thousands of objects that get created when you do that. It’s pretty impressive. [Chuckles] What a workout the garbage collector gets from that. But that can be a really big performance issue. And what James is saying, I agree with totally. If you’re doing stuff that is much more data-focused and less object-focused, keep it at a lower level and don’t pay the tax for Active Record of creating all of the structure for doing things that you’re probably not taking advantage of.

For sure.

Okay. I promise to shut up about it now. [Chuckles]

No, it’s all good. In fact, it’s really good. I’ve really enjoyed the conversations we’ve had about this stuff. Let’s go and do the picks. David, do you want to start us off?

Sure. I have a bunch of picks, but I’m just going to pick one today and I’ll save the others for later. Actually, I have two. For those of you that are junior developers, I am still working on The Job Replacement Guide. That’s it, JobReplacementGuide.com. And I’ve run it past my writing group. And the rough draft is complete and they are, my writing group are not technical people, and they have all come back and said this book is really technical-sounding. If you want this for the general population, you need to be less computer-y. So, I’m working on that. But those of you listening to this podcast, the book rough draft is probably already perfect. So, that’s something that you might be interested in. I hope so. Go out there and sign up for the mailing list. The book is still coming. And the other one is, I’ve been playing a lot of games that are in early release beta/alpha access, et cetera. And I’ve been playing Prison Architect, which is the most disturbing Sims game ever, because it’s The Sims but your citizens are felons and guards. And you have to build a prison. [Laughter]

And it’s actually really disturbing, the kinds of psychology. And the company that made it did it deliberately. They want to mess with your head. Yeah, basically the psychology of incarceration and what those involved in controlling a population that doesn’t want to be controlled, that sort of thing. So, if you’re into that kind of meta head-messing type stuff, prison-architect.com is the website. And it’s available on Steam. And I was going to say it was on sale, but by the time this airs, it won’t be on sale anymore. But you can check. They may be running a month-long sale on it.

So, those are my picks.

On Steam, you can always just put games on your wish list and Steam will email you the next time they go on sale.

Oh, very cool.

That’s nice. James, what are your picks?

I’ve got two. First of all, since we talked about Sinatra and stuff today, here’s a neat one I found lately. I haven’t had a chance to use this yet, but I love the idea. It’s a library called mock5 and it’s for basically mocking out Sinatra services. And what I love about it is you can have all these different mock, so the user action that returns just this canned info or the user action that throws some specific error. And then you can switch between mocks on the fly. So then, your test suite can be hitting the one that returns the canned information or returns the one with the error. And particularly, in case of the errors, man, it’s always terrible trying to get it into that one failure state. And this thing looks like it makes that really great, where you can just be like, “It will throw error 406,” and bing, then you can test it. So, this looks cool and I’m looking forward to a chance to use this in the future. So, that’s mock5. And then for your music listening pleasure, a friend of mine Paul has me listening to Frank Turner quite a bit lately. And he’s a singer/songwriter. And I’m really enjoying his stuff. So, just go check him out. I’ll put a link in the show notes. So, good music.

Awesome. Josh, what are your picks?

Okay. So, I have a JavaScript pick. [Chuckles]

No.

Yeah, yeah.

Wrong show.

This is the React JavaScript library for building user interfaces, UIs. And it comes out of Facebook. And they are in the process of converting the Facebook.com web application to use React for the rendering. I’m really liking React. I’ve only played with it for a day, but I took a piece of our application that was built in Angular that I didn’t really like how it was done in Angular. And worked on, oh, here’s a rough attempt at doing it in React by a novice. And it was really straightforward to do. And I liked what the code was looking like. So, I am hoping to have more to say about that later. But so far, it’s off to a great start. So, I encourage people to take a look at React if they’re looking for ways to do rich UI stuff in the browser. And apparently, it’s really nicely compatible with Backbone. And the common approach people are taking is using React as the view layer for a Backbone app.

Interesting.

Yeah. So, I’m liking that. Okay, so that’s that. And then I have a fun yet practical tip, or a pick. This new book that just came out called ‘NYC Basic Tips and Etiquette’, which is kind of hilarious but also super useful. This is a book essentially, it’s a cartoon guide to surviving New York City.

And it’s probably the best guide that I’ve seen for New York. And I want someone to do this for New York City [chuckles], I mean for us, for San Francisco. It’s like New York City because there’s a lot of very city-particular stuff in it, but there’s also some stuff that is broadly applicable. And I really like the instructions on basically how to get around on the sidewalk. And so, I’m looking at this as basically optimizing peer-to-peer interactions at web scale.

This is hilarious.

It’s like New York City is a city at web scale. So it’s like all the little things that don’t matter in a smaller city really matter at that scale. So, that’s what this book is about. So, that’s my pick. I’m done.

Interesting. Alright, I am going to actually do something a little different this week. One, I’m going to mention that we interviewed the guys behind React at Facebook on JavaScript Jabber. So, there’s a link there if you want a little more discussion on what React is and what it’s about. And the one I’m going to do that’s a little bit different is I’m actually going to talk about the other shows that I do. There are three other shows. One is on JavaScript, JavaScript Jabber, you can find at JavaScriptJabber.com. I also do a show on Freelancing and I get a lot of questions about freelancing from people that I meet. And there are a lot of terrific answers on that show. And that’s at Freelancershow.com. And the last one is the iPhreaks Show. I actually asked for names for the show and Josh was the one that recommended iPhreaks. And that one’s been going for about a year. And we talk about iOS programming. So, if you have interest in any of those things, you want to get better at JavaScript on your Ruby Rails, Sinatra, or other app, then go check those out. And other than that, feel free to go sign up for Parley, RubyRogues.com/Parley. And we’ll catch you all next week.