291 RR Building Ruby Gems with Brandon Hilkert
- Published on:
- December 21, 2016
00:30 – Introducing Brandon Hilkert
- Build a Ruby Gem 25% off for Ruby Rogues’ listeners!
3:55 – Building gems and the community
8:30 – Brandon’s process for creating gems (for beginners)
14:45 – Testing gems
17:00 – Writing the whole system into a gem vs breaking it up
26:15 – Why build Suckerpunch?
33:50 – What does it take to publish a gem?
- Ruby Gems
35:45 – “Gotchas” to publishing a gem
40:00 – Releasing gems that the community doesn’t need
Facebook Lookalike Audiences (Charles)
Mastermind groups (Charles)
Think and Grow Rich by Dr. Napoleon Hill (Charles)
Bark app (Brandon)
People socks (Brandon)
The Food Lab by J. Kenji Lopez-Alt (Brandon)
Charles: Hey everybody and welcome to the Ruby Rogues podcast. This week on our panel we have Jerome Hardaway.
Jerome: Hey everybody. How are you all doing?
Charles: I’m Charles Max Wood from Devchat.tv, gearing up for Devops Remote Conf. Go check it out at devopsremoteconf.com. We also have a special guest this week and that’s Brandon Hilkert.
Brandon: Hello from Pennsylvania.
Charles: Do you want to give us a brief introduction. I don’t know if we’ve had you on the show before.
Brandon: No. this is my first time. Sure. My name is Brandon. I’ve been working on Ruby since 2009 or so. Had a background in Microsoft systems administration before that and worked my way to development and more Open-source. That’s how I ended up with Ruby. I’ve been working on applications and products for the last seven years or so and with Ruby.
Charles: Very cool. You wrote a book called Build a Ruby Gem.
Brandon: I did. That was a couple of years ago. When I first started getting in Ruby and learning more about Rails a couple of years into it. It was clear that the community was strong because of not only Open-source but everybody’s contributions with Ruby Gems. To be able to put together a Rails application and do just about whatever you can imagine just by googling a Ruby Gem and a lot of times just putting it in the application.
For me, it was a big [00:01:35] moment especially coming from Microsoft and the closest since they had back then that all this stuff relies on people contributing and maintaining. That was my first [00:01:50] into a really strong Open-source ecosystem. Having gone through that and seen that, my first curiosity was how these things work. At that time I was working on an application and using the standard stack of Rails with authentication and authorization and most of the tools that people use these days.
I wanted to give back in some way and I knew that that required diving into Open-source Ruby Gems and understanding how they work, being able to help projects do whatever I could to make them better. When I wanted to go approach that, first question was what is a Ruby Gem and how are they structured, how do they work with the ecosystem as a whole. That’s really what’s caused me to dive in from a very analytical standpoint. My head wanted to understand every single piece of it before took the dive. I went in hard and tried to figure out all the pieces. It became clear to me that this wasn’t just a challenge for me on my own. A lot of people were having similar challenges. Not only for how Ruby Gems work and how are they structured but how do I get involved. If I want to contribute, how do I contribute? What goes into it? How do I find the right project? Do I just pick an issue off? Ways to contribute.
I think it first started with a blog post I wrote. It was called Three Ways to Get Started with Open-source. I first started the blog and posted it and did one of those [00:03:29] results. I thought, “Wow, men this is something I know people are thinking about too and it seems to be valuable.” That’s why I continued down that path of diving into what was interesting about this piece and what is it that people want to know more which ultimately lead me to Ruby Gems and their structure.
Charles: There’s more to it then than just using Bundler to create a Gem and then put in all of your [00:03:56] into the lib folder?
Charles: Yeah, I can see that. There’s definitely more to Rails engines than just create a gem with Bundler and put all your [00:05:09].
Brandon: I think the good thing about Bundler is that it gives you a lot of the things you need with a single command and I definitely use Bundler as a tutorial in the book. It’s all the details in the Gems back. It’s necessary to get started. You don’t want to have to dig into what methods are necessary on the spec file. It just gets you on it pretty fast.
For someone that wants to just dive in, a single command and then maybe a few methods, you have a Gem, start to finish pretty quickly. For someone who wants to take a more complex piece of code and modularize it this way. Bundler helps remove those pieces that are far less interesting, the scaffolding of the whole thing and giving you some [00:06:02] task out of the box to immediately release new versions, push to GitHub, all that stuff. With those tools now, it makes it pretty easy.
Throwing everything on lib directly could end up to be a mess if you let it. That’s not to say it wouldn’t work. It would definitely work. That’s one of the things where as I’ve seen people fortunately start to create new gems, it extends the ecosystem at the same time. It’s potentially negative because we have a lot of Gems in the community that are very good and do what you want so there’s less space to innovate in a sense of forfeiture [00:06:46]. It’s pretty unlikely somebody’s going to come out and say, “This is the new thing that every Rails app needs.” And that’s going to be the case. I think it gets people started quickly but there’s a sense of responsibility around the community in what you create and what you put out there to be public.
One of the common things that I heard a few times after I released the book but for people that clearly had a lot of experience in the community was well this is going to cause a bunch of different versions of random gems and there’s clogged up our community here with gems that are pointless or testing. I think that’s probably true in some sense that people made some test gems to try and see how things work, how they integrate in your application. At the same time, people need to start somewhere and I think that was a good place to do it.
I have a chapter in the book about the responsibility of the Open-source Ruby gem creator, pointing out those issues that create a duplicate named gems that’s already out there is not productive and it’s not helpful. If I go looking for the Sidekick gem in somebody else and there’s five GitHub repositories that you offer Sidekick. That’s not helping anyone. Now I need to dig into ruby gems maybe and see which one is the official release of Sidekick if I didn’t know. The naming is important to keep that out of the way from the existing tools out there and make sure you’re not walking on someone else’s toes and make it clear to that come after you if they choose to use your gems, which one they’re using.
Charles: That makes sense. I do want to back up a minute because I know that we have people who are new to the community. We always have new people coming in. Can you just walk through the process that you go through to create a gem?
Jerome: On a scale of 1-10, how do you feel your book correlate with [00:08:52] users. People who are new to Ruby because I think what we do are non profit, teaching them how to build a Ruby gem and doing some of the smaller things like using [00:09:05]. [00:09:07]. It’s an important skill to have if you’re going to be a Ruby dev. I want your input on that as well.
Brandon: The book starts with assuming that you know just a little Ruby. It doesn’t mean you’re an expert. At some point you have to make an example to build a gem. In the books case I used a lottery number generator. There are not tons of methods within the gem itself. It’s called [00:09:37]. It also doesn’t say here’s how to generate an array and here’s how to take a sample form the array. It assumes that [00:09:47] things that you feel comfortable with or that you’re savvy enough to look up to say, “Oh, I know what this method does.” Having said that, it also assumes that you’ve not created a gem before. It’s the basics.
To answer your question about the path, like Chuck said, to get started, if you have Bundler installed in your system which most do at this point. Bundler <space> gem <space> the name of your gem. Sucker Punch for instance is a gem I wrote a couple of years ago. If you are starting fresh, you would do Bundler <space> gem <space> and then the name Sucker Punch. It would create a project scaffold for you with a lib directory, a gems back rake file, all the file necessary to get your gem started and get writing code. It would sit that all out for you in a structure that was acceptable and made sense. Ruby gems are a self destructor if you want to do and know more than just package it. Ruby gems, in the sense, is that whole folder directory just packaged up. It can be uploaded anywhere but in most cases public cases are uploaded to rubygems.org which is the keeping repository for most of the functionality that people use in Ruby gems.
Jerome: Cool. Thank you. Thanks for expanding. One side point is that just the code structure. Bundler does give you a lot of stuff but if like me at the time I was working out at Rails application and I came into the Ruby community sort of with Rails all at the same time. I think a lot of people do it the same time although you mentioned that the camps are starting with React and [00:11:47], that’s awesome too. One of the things that’s not obvious if you start with Rails or a system that does some kind of auto loading, the code directory if you have a lib folder and you have an entry file in the name of your gem, you’re going to load all the other files that are in your gem and that’s not necessarily something that’s obvious to a lot of people. I think in a way Rails has spoiled us to know that if we put something in the directory , it going to be loaded and the name space would be there and it’ll load just fine.
One of the things that I go deep into is not only the structure which is predominantly a lib directory with some files in it but what you need to do to load those things inside, if you have dependencies and this dependency tree. How does that take place? You need to write more than just make sure the code’s loaded right, you need to have a module namespace, you need to make sure everything’s within it. That’s sort of being the good citizen. What are these kinds of community approved ways to put it out there?
Loading is a separate chapter in the book. That was one of the hardest things for me when I was starting to understand why it was that way and what was happening. It was all very manual. In the end, when I looked at it and compared to what I’ve known from Rails but at the same time this is truly lower level Ruby, it make sense when you put it all together. It also gives you some insight to what is Rails actually doing which is also an interesting topic but knowing where things are loaded, how they load knowing that this is just a bunch of Ruby files put together. It’s pretty incredible it works the way it does but there’s more to just like Chuck said, throwing stuff on a lib directory, you have to actually load the files.
Charles: One of the things that I go back and forth on with gems is testing. In particular, I have two thoughts about it. One is, is that usually when we ship a gem, we ship everything including the test and the people running the gem don’t necessarily need those tests, it’s only the people who are developing on it. If they’re going to customize it in some way then they’re going to want those tests but otherwise they don’t need them but yet all of that stuff tends to ship with the gems and I’ve wondered for a while if there’s a better way to handle that because people wind up using RVM or gem sets within RVM so they have four, five, six, seven copies of the gem on their machine. Then they have copies of all the fixtures and testing stuff and everything else. Is there a solution to that or is that something we live with as Rubyist?
Brandon: That’s a good point. I guess that’s dividing a line between did you download the gem for your application to just use the public interface or did you download it for development because in development obviously, you need all these other extra things. I don’t know off hand but it’s interesting to know the trade off whether it be file size or just storage needed on Ruby gems for instance. I think most gems are probably sourced from GitHub at this point. I’m taking a guess but they obviously need to keep those files there but if Ruby gems didn’t have all those extra development focused files and content, would it be more efficient? Probably. I’m not sure how much. It’s certainly simpler to push everything around together from an infrastructure standpoint. It’s always there but I hear what you’re saying. It doesn’t do your Rails application much good if you have tests that are actually being run or a bunch of fixtures that you download on your production server and then load it up every time you’re process starts.
Charles: One other argument I get into with people a lot because I agree, I don’t know if there’s a good answer for that one but I was curious what your take was. Another one that I get in arguments with people about a little bit is whether or not they should write the entire system into a gem or whether or not they should break it up. For example, Rails is a gem. Rails is mostly a wrapper around a whole bunch of other gems so it polls an active record in JSON and all the other gems out there. It’s a huge gem. Even if you come down a little bit and look at active record or active records built on active model and active model does a ton of stuff. Active model actually has like five or six modules that you can poll into your own class to make an activerecord compatible class. Should it all be in one ginormous gem or should you be able to just poll in say active model validations? Just poll in those little pieces and then compose your library out of that. I only need the validations, I don’t need the other bit that active model provides.
A lot of the questions were around why need an engine because my business models, the active record based models were common across all these apps. I want to extract those and put them in a gem. How would I do it? Or how would I do it if I want to have migrations? I sensed that people were doing it because that’s what they were lead to believe should happen. It felt like the [00:19:27] maybe. Clearly you could copy those to another app which I’ve done a number of times and it works just fine. But in a lot of sense, real early on, at least when I was starting ruby, it was all about being dry and not having this logic all over the place duplicated while dry doesn’t necessarily mean exactly the duplication of the lines. People took it a as that. Many times you copy and pasted something that was seen as a no, no. They want to do the right thing and extract kit.
I’ve seen people get into some pretty dicey situations with just extracting business models which you can imagine are part of everything you do, the core of it. Really working out the testing strategy with that, they always need to be involved with the host app to work properly. I’ve seen that really go down some of that path. For personal experience and products I’ve worked onto that were technically engines that had database back tables. It can get messy especially when you’re sharing it across a bunch of applications and then you’d make one little change and you need to update it in everywhere. That may or may not be the case if you would copy the file depending on what the application needs.
Charles: I’ve actually been there. Devchat.tv, we’ve all used the app that did this. Devchat.tv, before I moved it back to wordpress was actually set up and had admin app, had sponsorship app and had a bunch of other services basically that made up the entire system. I wouldn’t say it was painful. It was closer to excruciating but I definitely hear what you’re saying there.
Brandon: What were some of the bigger issues that you remember?
Charles: For example, sometimes we’d make a change, we didn’t think would affect one system but would affect another system and then it would turn out that, “Oh, wait this doesn’t affect that system.” Or we’d get through a deploy and we’d find out the three versions that go in our cord gem, oh, there was the small issue that we changed something and it turned out not to be an issue in the app we were actually working on but it did turn out to be an issue in this other app.
The other thing was there was a lot of mental gymnastics that had to happen just to keep track of what was happening where and when and why. Even when everything worked it was like, “Okay, I’m making this change. I think it’s going to have this effect.” But we were never quite sure because the use cases were different in all the different apps. The only way to really test it and make sure that everything worked everywhere was to run it everywhere but nobody wanted to actually run those tests everywhere when we changed the core. We ran the sample that we run the test on. It cut most of the bugs that we wound up writing before they ever got deployed but at the same time it was really, really painful.
If I had to do it all over again, I would probably consider just writing those model into each system and then having one system responsible for the migrations because that’s the other bit that you have to deal with if they’re sharing your database. The other thing is then I could put the logic that each of those apps cares about and if there is some shared logic somewhere then we could just break that into a module that isn’t dependent on the state of the model and just do it that way.
Brandon: That makes sense. I work on an app now that does a lot of that. I’ve just copied it over. One of the things that I noticed real early on, in the Rails app for instance the validations for the core production app for customers were different than what might have been needed for an admin. You get in the state, maybe the customer did something to their account and it’s in a place that’s not great and they need to come fix it or something. You go into the admin app and the admin has some ways to change, if it [00:23:50] app you might have to change the subscription or a trial date. You go to update that, it’s no longer valid because of some things that the customer is controlling. Validation fails and it says their email isn’t valid and you’re like, “Change in the trial date. I don’t care about the email.” Let’s assume they’re on the same model. You’re stuck and you’re in a position where you say, “Maybe I don’t want this validation on the admin app.” Now you’re left to say, “Well, if it was an extracted gem, should I could put a conditional in?” I don’t know. Do I give the host some names and say, “Don’t apply this if it’s that host.’
And then you go down this rabid hole of conditional logic which from the start you’re like, “Man, I wished I just copied that model in there. It’s like four lines for the admin app.” I’ve copied them lately and been perfectly happy with it. There’s been a few cases where I changed one thing and say to production [00:24:48]. It was necessary for the admin app but I’ve also reserved myself to the fact that admin app can blow up every once in awhile and it’s not the end of the world. I don’t want the customer app to do that. I’ll those instances where I just need to fudge a line or I forgot to make a change over. I’ll take those over knocking production over for sure.
Charles: I’m sure we made a few people throw up in their mouths, you copy hoe.
Brandon: Yeah right.
Jerome: I have a question. I want to get more into your experience. The idea of the why behind building certain things. I only got into the why of building Sucker Punch. We just spoke about Sucker Punch about a week ago and I really wanted to ask your opinion on why did you feel like the community need that type of gem. [00:26:37] Ruby [00:26:40]. [00:26:43] or maybe building Sucker Punch was able to help the community?
Brandon: I’ll give you a sort of like a more [00:26:55] process of this because it was a stepping ground for me. When I mentioned I wanted to dig into the Open-source ecosystem and do some work there, part of it was I wanted to just learn about some code or approaches that I hadn’t seen before. I was pretty isolated in my role at that time. I wasn’t in a big team. I wasn’t surrounded that had tons of experience and I really wanted to learn. I thought a great way to do that was to contribute and one of the things that I knew that I needed to work on and I needed to understand better was multithreading and how you can implement it in Ruby.
At that time Sidekick was and probably still is the most popular project to deal with multithreading. I approached [00:27:49], the maintainer and was looking to get involved. At that time we were a big use of Sidekick and the dashboard for Sidekick was something that I used all the time but there were some elements of the dashboard that I wanted to be better. There were some pieces that for instance, when you looked at the dashboard, you could refresh it will give you some stats but it didn’t auto refresh so there were times when we were batch running jobs and I want to know how many process didn’t last a couple of seconds and I couldn’t figure that out just by looking at the dashboard, maybe refreshing a second later and try to do some math or whatever.
If you’ve seen Sidekick today, there’s some process graphs on how many jobs are processing and that was something that I wanted to implement but it turns out that much of the backend API data piece was not there. I spent a lot of time digging to Sidekick which calls me to dig into gems, understand how they were structured then ultimately because I wanted to be exposed to a project like Sidekick with thread, I figured in a way I can contribute my experience with web and maybe add this functionality to the web UI, ultimately just getting exposed to the other pieces that I didn’t know. It just helped me move along my experience with multithreading within Ruby.
I dug in there and that’s what got me exposed to all that and feel more comfortable. At some point I was doing some apps on the side just for fun and I had an app that was hosted on Heroku and it needed to do some heavy background work. You’re dragging in Sidekick. Certainly would have worked but being a thrifty night and weekend developer on this random toy apps, I didn’t necessarily want to spend up a whole another dino for just the Sidekick worker. At that time, this is before Heroku’s pricing model changed but the dino was I think $35 [00:29:44]. This app that I didn’t really care about but actually people were using surprisingly, I’d have to start incurring some cost there. Being sort of like savy development type, first was like, “Well, how can I not spend the money.” One of those ways was, “Well, if I were able to do this work that want to do in the background in line it wouldn’t cause me any money because I have this free web dino and I wouldn’t have to spend up a new process to run these background jobs.
[00:30:15] was a gem that at the time my [00:30:18] also maintained. It had that same model that within a single web process you could do some background work. After talking with him quite a bit through my Sidekick work, I realized that it was an implementation that was older and I don’t think it was something he wanted to continue the way it was. At the time, Sidekick used Celluloid which is still a framework to do multi trying in Ruby. I got into that and I thought, “Well, it seems like it would be pretty easy using Celluloid the way Sidekick does but just do it in a single process. That was part of my learning experience about all this multithreading and how does Celluloid work. The first version of Sucker Punch was using Celluloid. Actually, to be frank it wasn’t very complex at all. It was a few files and it was really a DSL on top of Celluloid because Celluloid had all the tools I needed to make a background cue but it was somewhat verbose in a way that you would set it up and it wasn’t clear when you weren’t necessarily writing a job, you were pushing this thing onto mailbox in one of the classes that Celluloid was loaded into.
Just creating an easy to use DSL like Sidekick did for jobs and cues doing the same thing with Celluloid was easy, Sucker Punch was born out of this need to run jobs within a single web process and not incur the cost of another web process. It doesn’t necessarily have to be monetary but process wise your production servers wouldn’t need an extra process either. Having said that, I don’t want to suggest that that’s going to save everyone’s day because there are obviously some downsides. There’s memory bloat in the single web process and obviously if the web process dies our jobs die too so if you cue up 1,000 jobs and you cut the process off, the number of jobs that didn’t finish are gone because they’re stored in memory and not [00:32:21] as in the case with Sidekick.
There are some tradeoffs but for me, I was doing work at the time that didn’t matter. I would always get updates and the update if I miss one in between would’ve taken care the one in the middle so it wasn’t a huge deal. Up to this day, I still on a Sucker Punch still suggest that it’s best to use first thing like logs. Logs in a sense of if you don’t care of a few drop, they don’t drop but for some reason your server dies, they will be lost if there was a bunch of GitHubs.
There are some tradeoffs but at the same time for my used case it didn’t really matter. I wasn’t thinking very holistically about what does the community need and [00:33:05]. What’s the next version of [00:33:08]. It was really just a used case for me. I used [00:33:12] in the app that I was working on and it worked just fine but also at the same time, “Oh, what if we did this differently?” I don’t know whether it was just about visibility into the project or right time but people seem to latch onto it. I feel like it’s being used in the similar case where you have a small app. You don’t want to really have an extra process to run or whatever that cost money and you’re trying to do things cost efficiently and Sucker Punch gets dragged into those situations.
Jerome: Roger that. Alright. Thank you.
Charles: I want to go back to gems here for a minute because there’s another end of gems other than just, “Hey, we’re going to publish this. Don’t name it something that somebody else had already named it.” And that is Getting it Published to Ruby Gems. In the example of Sucker Punch, what does it take to put it up there so somebody else could use it? I think I’ve done it. I’m guessing Jerome’s done it but for those people who are getting their little library written or maybe their big library written then they go, “Okay, I want other people to be able to pull this down to Ruby Gem.” How does that get on somebody else’s computer?
Brandon: I think once you do it the first time and create an account on Ruby Gems, it’s all easily handled. Realistically, at this point if I want to release a new version of Sucker Punch, I type [00:34:35] and that’s the end of it. Assuming I’ve versioned everything properly, incremented versions. Let’s say I’m on version .4 and I want to go to .5, I bump a version file up and then add the appropriate change logs and do all those other sort of developer responsible tasks. [00:34:54] is the end of it.
If you’re staring you don’t have an account Ruby Gems. You would create an account there and you would associate your gem which is done through the gemspec file to your email or your account that you’ve signed up with. After that, I think the first time it asked you to sign in from the command line, it all just works from there so it’s pretty easy.
Charles: Yeah and if I remember right when you sign up for that account, it’ll give you a walk through. It’ll tell you what command [00:35:27].
Brandon: Gotcha. I think that’s one of the benefits with using Bundler in that your rakefile has some files loaded to make all those tasks pretty easy for you. I think there’s a release command and install. There’s probably some more but it has everything you need and it is pretty easy to get started.
Charles: Are there any gotchas then to this whole process of writing a gem or publishing a gem?
Brandon: I think the only gotchas are more about doing things in a way that is maintainable and helpful. As a community, we have a ton of options for all different kinds of functionality and I think the Ruby community has grown up feeling like, “Okay, just add another gem to the gemfile. Life’s problem will be solved.” That’s sometimes the case but there’s also plenty of gems that may not be good citizens in the ecosystem and we’re left to figure that out on our own whether inspect the gem itself or we take recommendations from colleagues that we trust. There is definitely an element of trusting how that gem is set up and what it does because you’re ultimately putting this code into your app and saying I trust everything it does. Not only that but I potentially trust newer versions of this gem, depending on how you load the gem into your application and whether you allow updates and you bundle update regularly or you say only a certain minor release.
We’re allowing this code to be in our application so again, going back to that responsibility piece, really knowing how these things work is sort of being that good Ruby community citizen because if this code will be used and you hope that it is useful for other people. It’ll make your application better but also it could have some downside to it. If we load some code and it’s in this global name space and we overwrite some methods and you’re not really sure what happens. You see these issues a lot of times if you will look at gem repos that there’s questions. People are confused. I think just having that all straightened out and knowing lay the land really helps to be that good citizen in the community if you’re going to publish and maintain gems especially. That’s another piece of it. It’s the maintenance part.
Clearly, there’s a responsibility to putting something out there but then letting it die is not doing anybody good. If you extract some functionality from your app or something that you have an expertise in, that you believe others will use. It lets say otherwise obviously that this is out there and you may not update it ever but you also try to be respectful about the state that the code is in, whether it should be used whether you feel good about it, that kind of thing.
There’s plenty that I’m sure we’ve all seen that have rotted and you really don’t know what to expect. Whether that’s looking at the gem and understanding what to look for. Do you look in there and there’s no test, there’s no spec directory, there’s no test directory. How does that make you feel? Is that good enough? Is the functionality minimal enough that it doesn’t really matter to you? There are a lot of elements to go into trusting code but adding a gem into your application is not a task that should be taken lightly. It does have potential consequences. I think there’s an element of scrutiny that’s required to build long standing applications that won’t be a maintenance burden.
Charles: Got you. One of the things that I wanted to go into is I know some people go out and they write yet another [00:39:56] or something. It’s a gee whiz project and, “Oh, this is fun.” I’m learning how to [00:40:03] and then I think, “Well, somebody else may want to use this. Should they release it as a gem for other people to grab?
Brandon: I don’t see why not. One of the things that you can hope for if you can release code is that others will chip in and help you if they want to see it pushed forward. If there’s some functionality that your new [00:40:23] does that others don’t but yet it’s incomplete. You’ll start to see pretty quickly that if people are using it there’ll either be issues or feedback whether it’s from Twitter, whatever place you want it sent. I think starting to see that feedback, you hope that not only will people add feature request but they’ll also chip in.
One of the things you can do to be more explicit about that is on the README, be explicit about your contributions and what you’d like changed or whether it’s a pretty licit issue that you say, “Look, this is where I want it to go.” Sidekick is another great example. I think [00:41:09] does a fantastic job of managing the project and he has a luxury if doing that because people are paying for the paid versions of Sidekick to help fund his support of that. If he’ll put an issue about a feature that’s not there yet but he sort of wants it to work, you’ll see people chip in and offer some feedback about well in my app this wouldn’t work that way because of x, y and z. It’s good to get feedback like that. Whether you do it in an issue or in the README itself or through maybe a change log. There’s a variety of ways to be explicit about what you want help with or how you want contributions to work. Being explicit is a great first step and fostering that sense of community and making it clear that you love help if people are interested.
Charles: Alright, well let’s go ahead and do some picks. Jerome why don’t you start us off?
Jerome: Roger that. It’s close to the holidays so right now has geeks in their life if they’re trying to figure out what to buy for but they don’t know what to buy for. I chose one website in particular. My only pick for this week is thinkgeek.com. It’s a really fun website with a really diverse set of gifts. My favorite one personally is the No, I will not fix your computer tee. That is something I saw recently that I have liked 100 people in my context to buy this for a perfect gift. That’s my pick for this week.
Charles: Yeah, I’ve actually told my family, my brothers and sisters, my wife’s brothers and sisters and everybody else. I’m like, “Look, if you aren’t either my parents or her parents or our grandparents, the answer is no unless you catch me when I’m high on something.”
Jerome: I have a wife that will just [00:43:21] on their behalf. Basically it’s immediate family both side extension but else out of that, no. Cousins and whatnot, I can’t help you.
Charles: Yeah, I have nine brothers and sisters and it was happening rather frequently. That’s when I put my foot down. I’ll jump in with a couple of picks here. The first pick I have is I’ve been playing around with Facebook ads. I found the lookalike audience on Facebook ads awhile back and I thought, “Oh, that’s cool.” Essentially what you do is you upload a series of emails and then they find the people on Facebook that have those emails and then they munch through their profiles and they figure out the common threads between those people and so then you can advertise to people like the people on that list. What I learned is that you can also upload a list like say your email list and you can retarget ads back to those people so instead of a lookalike list, it’s the list. I think that’s pretty awesome. I’m looking at some ways to make people a little bit more aware of things like Devops Remote Conf and stuff like that. Anyway, it’s been really awesome to learn about these things.
I picked it up from a mastermind group and that’s the second pick I’m going to put out there. That is having a mastermind group. I do one mastermind group that’s live every week. It’s on entreprogrammers.com. I have two others that I meet with every week. One just started. The other one I’ve been on for about a year and a half. I think three is too many actually, two is enough, one is enough if you’ve got the right group but the one group is focused primarily on business. The other one, we talk about business but we also talk about family, kids and relationships and stuff. I get two different sets of input from them. I talk about things that I’m trying to do better or things that are not going the way I want or things like that and they encourage me to do better. They give me suggestions on how I can do this better and all those things. Having a group like that that you meet with every week and you check in and you have some accountability and they help you figure this stuff out has been valuable. If you’re out there, even if you’re not in business for yourself, just for career, family and friends and everything else, it’s just nice to have that input in your life so I highly recommend to people that they go out and they find people who have similar concerns to them that have different experiences than them and form a group and then share your experience and help each other out. It’s been very, very helpful to me. I guess the overall pick if you’re going to put a bullet point under this mastermind groups but there’s a ton more than that. It comes out of the book Think and Grow Rich which is a terrific book too so I’ll pick that too. Brandon, what are your picks?
Brandon: Cool. My first pick is somewhat self serving and that’s the app that I work on everyday. It’s called Bark. We make software to help keep kids safe online. If you have kids on social media, email, text and you’re worried about both incoming and outgoing messages that may not be appropriate, we make some software to do that. I’m really proud of the work we’ve done and some of these things we’ve been able to help families with.
Brandon: Oh, you do?
Brandon: That’s exciting. I appreciate, thanks. Two non technical picks, the first one is, as someone who doesn’t love cold weather, I struggle with the right socks and working at home and slippers so I recently got into merino wool socks. As a runner, this comes up in running socks a lot. It’s great, it’s moisture [00:47:24]. I found they’re also pretty expensive at times so I found some socks called people socks on Amazon and it’s a four pack and it’s only $22 where you can find a single pair of these types of socks for that price at times two. Really high concentration merino wool and they’ve been awesome so far. Only a month and a half to it but so far so good.
My last pick I a book called The Food Lab. I recently got it. I’m not a huge cook but I enjoy eating and I enjoy cooking when I do it. This book is a huge book, probably a thousand pages or so but it has tons of technical experiments with food. This is a MIT engineer that got into the food industry after school and just kept down that path but he took a very scientific approach to learning about food and how things cook into really fine details. I think most engineer types would enjoy this if you have any interest in food or whatever topics. How to make the perfect burger? The perfect hardboiled egg. I found it fascinating so far and I’m just through the breakfast section. It’s called The Food Lab: Better Home Cooking Through Science. Even if you don’t love to cook I think there’s some fascinating science and really data driven approach to cooking meals and making things great through preparation and cooking. It’s been fun for me. It’ll certainly give me plenty of entertainment since I’m probably a hundred pages into a thousand.
Charles: Very cool. If people want to follow up with you, see what you’re doing, read a blog, check you on Twitter or anything like that. Where do they go?
Brandon: The website brandonhilkert.com. I have a regular blog that I post out to. You can sign up for the mailing list there if you’re interested in keeping up or just deck back every once in awhile. I’m @brandonhilkert on Twitter too, same with GitHub. Pretty easy to find me. I don’t really hide anywhere but you can all my work on those places and I would love to hear from people if they have questions or thoughts or whatever. I’d love to chat. Open to it.
Charles: If people want to get your book?
Brandon: It’s off my site, probably easy way, just go to brandonhilkert.com. there’s a book link on the left there and click through and you’ll see the book. There’s a couple of packages up there if you’re interested with Screencast and some other stuff for your team if you want otherwise the eBook is up there. A bunch of different versions and everything. You should have everything you need from there. There’s sample Screencast and a sample chapter if you’re interested in that too. Love to hear feedback on it.
Charles: Awesome. Your notes for us for the show says that you can get 25% off if you’re a listener. Just follow our link.
Brandon: Yeah, that would be awesome. I’ll have the link up there. If they’re free to hit that and let me know if anybody has any feedback or thoughts.
Charles: Sounds good. Thank you for coming Brandon.
Brandon: Thanks a lot. I appreciate it.
Jerome: Thank you so much Brandon for your insight.
Brandon: No problem. It’s been fun.
Charles: Alright, we’ll catch everyone next week.