The Changelog: Software Development, Open Source - Devhints - TL;DR for Developer Documentation (Interview)

Episode Date: February 9, 2018

Rico Sta. Cruz joined us to talk about his project Devhints (cheatsheets for developers). There are more than 365 cheatsheets you can contribute to and it's open source. We talked about the design, technical implementation, community, alternate interfaces like the command line. We also talked about RSJS, RSCSS, and Docpress.

Bandwidth for Changelog is provided by Fastly. Learn more at fastly.com. Error monitoring is provided by Rollbar. Learn more at rollbar.com. And we're hosted on Linode servers. Head to linode.com slash changelog. This episode is brought to you by Command Line Heroes, a new podcast from Red Hat. In this podcast series, you'll hear true epic tales of the developers, the hackers, and the open source rebels revolutionizing the tech landscape. Here's a preview of episode number three, The Agile Revolution. I'm Saran Yadbarek and this is Command Line Heroes, an original podcast

from Red Hat. Today's story begins in February 2001 and it's set at a ski lodge in Utah. We turned up at a lodge, you know, the pine beams and the fireplace and the entryway. We got there the night before and we basically just sat around and talked about what we're going to talk about. And the next day we turned up and we'd reserved a meeting room. We took the tables and moved them out to the edge and we just put the chairs in a circle or an oval so, you know, we could basically be facing each other and, you know, somewhat more open. These guys were open source developers, so staying open was kind of their thing. That was Dave Thomas. Dave and 16 others got together at Snowbird Ski Resort that winter,

not to ski, but to talk about what was wrong with the developer's world in the 1990s. I say talk, but argue might be more like it. They had originally met at a conference called OOPSLA, Object Oriented Programming Languages and Systems. And it was actually at that conference that they realized they all agreed that creating software was messy. They just hadn't agreed on what they should do about it. So the meeting on the mountain at Snowbird, that was where they were going to try and nail down a solution to that problem. The agile revolution and the resulting methodology has impacted every single one of us. Your epic true tales, just like this one, of hackers who transformed tech from the command line up.

Subscribe where you get your podcasts or visit red.ht slash command line. Once again, red.ht slash command line. All right, welcome back. You are listening to The Change Log, a podcast featuring the hackers, leaders, and innovators of open source. I'm Adam Stachowiak, editor-in-chief of Change Log. Today, Jared and I are talking to Rico Cruz about DevHints.io, a cheat sheet site for developers. 365 plus cheat sheets you can contribute, you can give back. It's open source.

We covered the technical implementation, the design, the community, alternate interfaces like the command line. And we couldn't help but recall Defunct's cheat tool from back in the day. We covered RSJS and RSCSS, two projects he has for reasonable systems for JavaScript and CSS structure, and also his project, DocPress. So, Rik, it's 4 a.m., and we're excited because normally we do this show at 2 o'clock p.m. our time, but it's 4 a.m. your time.

How do you feel? Well, you know, I haven't really had coffee yet, but I'm really excited to be here. I mean, I didn't really expect anyone would nominate me. And basically someone just mentioned on GitHub that they should have me on the show. And I got a notification ping and it said like, hey, why not? You know, I've been tuning into ChangeLog and I'd be excited to do it. So here I am. This KZAP on GitHub. So at KZAP, a fellow Philippines native with you, Andre Marcelo Tanner, I believe.

Is that right? And he had lots of great things to say about you. Different talks you've given and the things you've done, everything from phenomenal cheat sheets like, what is it called? Devhints.io, which is awesome. And various other projects we'll talk through. So that's awesome. Rico, we have to apologize about the 4 a.m. wake-up call

because like KZAP, you're over there in the Philippines. And I was not thinking about that when I scheduled our regular 2 p.m. time slot. So thanks for waking up for us. And why don't you help us out by understanding really the vantage point of open source and software development over there in the Philippines? Very interesting question.

So the guy who nominated me, Kezap, he's actually part of a local Slack group that we have called phackers.com, which is Philippine Tech Hackers, which is pretty good because it's only in the last few, two years maybe, two to four years that we were getting people online and people are starting to congregate

online and the way philippines is is it's pretty fragmented there's a lot of cities and we have some meetups but it's not as active as you know it would be in other countries. So a lot of things happen online. But we do also have local meetups for interest groups like JavaScript and Ruby. So it's very nice to see that people are actually getting interested into open source, especially now that the open source community is getting pretty big as well. Very cool. One of those, the main one I believe that you're a part of is the Manila JS JavaScript Community Meetup.

Sounds like a lot of folks interested in that. And you got some big speakers as well as yourself talking about such topics as why is NPM slow? Of course, we'll get a little bit to PNPM down the road, but great to hear that there's at least a start of a local community where people are getting together and doing cool stuff. Before we get to the major topic,

which we want to talk about your cheat sheets, these are things you've been working on for a long time and you finally gave them their own home on the web at DevHints. Let's hear a little bit about you, Rico. Tell us a little bit about your origin story. How did you get into the software game, and what was that all about? Actually, my background is more into graphic design, and I was doing a lot of UI and web design

before I got into this whole web development thing. And once upon a time, my day job was doing plainly web design without any sort of coding. Then I met some very interesting people who are way smarter than me, who are into this thing called Ruby, which was very, very new to me. And so I gave it a shot, and we co-founded a small startup back a couple of years ago. And it basically started from there. And I didn't really have any professional experience with web development at all before this. And suddenly I was there doing Ruby, doing Sinatra and Rails and all these things

that would help some other people who have a lot more experience than me. And that's pretty much it. And eventually I started being somewhere in between. I was a developer slash designer. And that was 2009, I think. And I was just kind of the person who would like to make things. And every now and then, I'd make a project

and realize how easy it is to get things online. Now that we have Git, we have GitHub and all these platforms. And I remember asking my friend, how do you get something out there? Is there a process? And he told me, well, I don't know. Push it out there and tweet about it. And that's what I did.

That's funny. We've been hearing this for years. We started this podcast in 2009 that's kind of like that's been somewhat of the maintainer open source uh inventor you know feeling is like i created it how do i market it how do i share it with the world and that's generally what people did but part of the motivation for us to do this show and you know the the blog we've done in the past and the newsletter we created was to shed light on the interesting thing happening in open source. Oh, yeah.

You know, a lot of times people would ask me, like, how do you get a project out there? How do you get it popular? How to get people to look at it? And there's really, I think, no good answer to that one. And sometimes you never really know. I was hoping you were just going to school us and give us all the tips and tricks right here. What worked for you? What were some of the things you did that seemed to work?

I could tell you a couple of things on what I think worked, but I can't really say if it is what contributed to the success. One of the interesting anecdotes i would tell my friends is that you know there would be times that i would pour my heart into heart and soul into something that i really like doing i would basically make an entire compiler of javascript because that's what like to do. I like to tinker around with compilers. And while I built it, I built JSTCoffee based on another ASD generator. But the thing is, these are the things that I like to do.

These are things that I would stay up all night sometimes just to build. And sometimes the smaller things that seem like they don't matter, like I made a small progress bar, and suddenly that's a lot more popular than something I put so much interest into. You just never really know which things would become popular. But I think what really helped in general is you have to understand that the people who go to your project on github or on their website not necessarily people who would be using your work so your intention should be how do I make something and explain it in a way that would interest people. Like, let's say, for example, you're making,

well, I'm not sure, like a React component, and you might be talking to someone who's not really using React, but if you tailor your readme or your website in such a way that makes it seem like, oh, this is actually an interesting one and I might be using it right now, might be using it in the future, or a colleague might like it.

You know, you have to sell what it is you're building in your documentation. It's not just describing what it is and how to use it. It's also telling an interesting story. Any examples of what an interesting story might be like you say selling what does it mean to to sell someone in a readme um it's actually very straightforward i think i mean you would see a lot of projects out there and they would be wondering why people aren't really looking at it but there's usually no examples or no screenshots which is kind of a bummer compare that to something that even it might be a simple project but it has a very clear screenshot

describing what it is like oh just at a first glance in 30 seconds into the readme you kind of already know what it is well if, for you as your in-progress project, since you mentioned that, I think the landing page for that is just perfect because you've got four examples there. You click it and you see it literally in progress. You see it working, which is the point. I think that's sort of like the get to the point

is kind of what you mean by selling. Yeah, exactly. It's something that you go to the website and within 20 seconds, you know what this thing does. Yeah. I was thinking about this for us, Jared, because we use Turbolinks.

Yep. Sort of using endprogress.js for us? Well, it says right there, perfect for Turbolinks, Pjax. Doesn't Turbolinks 5 have that built in doesn't ours do that yeah it has that built in now we have that feature Adam it's just our website's too fast

you never see it I never see the progress bar because it is just that fast that's a humble brag yeah our code is on github so if you want to check it out you can cool I was going to say it out, you can. Cool. I was going to say, it's not anything that we did that's special.

There's a lot of very smart people that made it fast that weren't us. That's from the Ruby community, right? Which one? Turbolinks? Turbolinks, yeah. Yeah, it came out of Ruby on Rails. Right. But it's a standalone thing now.

Yep. Speaking back to your point there, Rico, about demoable. We share a lot of projects. Like Adam said, it's what we do. They're rarely ever our own things. We're trying to help other people get the word out about what we think they're doing, which is interesting. In the days of analytics, especially with Twitter metrics and stuff, we can know after the fact what did and did not resonate with the community of people that at least follow the changelog handle on Twitter.

And what I've seen in the last probably two years, but now it used to be somewhat avant-garde and now it's commonplace, is the rise of animated GIFs in order to embed a movable, demoable, visual thing right there at the top of your readme, which I think probably today, if you had to pick one thing that would sell a project, is a high-quality animated GIF

that actually displays the value proposition of what this thing does before you get to all the details of its technical merits and how you use it and stuff. It's like, just like here you have on InProgress.j, it's like, let me see it right away. And if you can't do it on your own website, if you're going to read me, animated GIFs are a great way of doing that. Oh, yeah. And it's very true. And it's also very portable because they show up on GitHub, on NPM,

on Twitter, on pretty much everywhere. So that's absolutely great. It's actually pretty interesting to see how much just developers love animated GIFs and emojis. Right. And I didn't expect it to happen that way. It was funny because at first, when i think my first exposure to emoji and adam maybe you can recall this too i think it was when apple added them to the iphone keyboard back in like ios 4 or something i mean besides like the old emoticons

and then like skype had some weird looking smiley face. Besides the typical smile, laugh, blah, blah, blah, the full icon set, at first I was very down on them. I thought these were for kids and silly. I don't know. Then over time, they just swayed me. Does that resonate with you guys or was I just a curmudgeon to start with and you all thought they were awesome from the start?

I'm with you. My, at the time, girlfriend, now wife, Heather, she was before the Apple swing. It was when you had to actually install that separate keyboard. Oh. It was like an app you could download and you had to go into your keyboard settings and like add this Chinese or Japanese, some sort of, you know. Character set. Yeah. Some sort of character set that you had to add.

It was like special thing. Yeah. And it wasn't, it didn't even, it was sort of like kludgy. And I can remember seeing like weird characters and I couldn't see the things because I didn't have the keyboard in place. So this is pre-then. I'm like, you and your friends talking these emojis or whatever these things are? I didn't get it. So clearly I'm

born in 1979 because I'm showing my age. But I think they're cool. What about you, Rico? Well, we got people putting emojis in commit messages, putting them on blog posts, and pretty much anywhere you can squeeze in an emoji.

Command line apps all have emojis now. So it's actually pretty interesting just how much emojis have been starting to ingrain itself into open source developer culture absolutely and uh that's another thing we talk about things that optimize for uh you know for the retweet or the star in terms of you know projects will put an emoji in their description and so there's something about it that just i don't know, there's just a visual aid or you find the right emoji that represents your little

library or whatever gives it an extra little boost. So it's funny how pretty trivial aspects. I mean for people who, the developers were usually about meritocracy and like what's the technical merits of this thing and very much the

numbers and the tech and the architecture. But at the end of the day, we're all very much just sold by animated GIFs and emojis. Well, I like to think we're sold about the usefulness and the merits of projects. And those are just things that we use to convey them. Well, at least that's how it's out. Not at all. I would like to believe that as well. That's probably, as with all things, the truth is probably somewhere in the middle.

I think what's interesting, too, to go back to the earlier conversation around the vantage point you have on open source and you mentioned how the community is getting driven and how recently the Slack was formed and there's community being formed. What do you, what do you see as community drivers for, for you in the Philippines? Do you feel like, you know, in the United States or in Europe or different areas, you feel like they're, they're more advanced or where do you see the Philippines and your local area you know in terms of like developer community okay so whenever i go to meetups in other countries one thing i would

really notice that is different from here and over there is just it's something about culture as well of people being in a room with other strangers. And there are some cultures that welcome this kind of setup very openly. You would go to meetups in other countries and they would be more like parties. They would be very social gatherings. And this is wonderful. The thing about our culture here in the Philippines is a lot of people are pretty shy a lot of people aren't really that outgoing so as a result sometimes we don't get a lot of people attending meetups or when they attend meetups it's it's just a different kind of vibe than it would be in other places and one thing I think is great is,

you know, now that we have online communities, we're starting to get people out there connecting to more people, not just offline, but also online. So I think that's great because it really goes well with our culture of, you know, being reserved people. And I remember a couple of years ago,

there would be a lot of great talent. There would be people who are really great at what they do, but you just never really hear about them because you never go out. They never really put themselves out there. And now that we have more avenues to express ourselves, we got Facebook, we got Twitter, and I think it's just really

fostering this really good sense of community. Do you find that you have more, I don't know, you're less shy, more outgoing, more confident online than in real life? Like, does the community reflect you in that way? Or do you feel like you're somewhat different from your surroundings in that regard? I don't really know. There would be times that I would feel a little more seclusive. There would be times I would feel pretty outgoing. So just like any other person, I probably have different moods and swings.

So I'm not sure I would be a good representation of everyone. One aspect that I, just looping back to the little bit of the sales side, which is a term that probably a lot of us don't love, like selling your open source projects or getting people interested, whatever you want to call it. You mentioned that you really came from a design perspective into software and open source. And that's very much reflected in all of your work.

I mean, if you go to defense.io and then your other project, rscss.io and the JavaScript one, which is very similar, they all have very thoughtful and just, I would say, aesthetically pleasing design. That seems to also play to the strengths of getting people interested in your work. Have you found that to be something that resonates with folks in terms of the amount of design effort you put into it? I can't really say definitively that it's a yes or no, but there are people who would say that it is.

There would be people who would say that they're more interested in something because it doesn't look ugly. So I think there's definitely something there. Yeah, like I said, I came from a background of design. So sometimes just to make open source projects is probably one of my excuses to design something. Yeah, I think from that perspective, I'll say you're very fortunate because there's

many of us, and I can put myself in this particular bucket, where I have a taste for design but no ability to create it. And so lots of times that will stop me from releasing things or I dread creating the super simple website that I know this thing needs because I'm going to struggle so much by not living up to my own standards in design. It seems like so many open source

projects could benefit so immensely from design help and there's like this chasm that we need to bridge between the two. I think I don't have any real answers on how we could actually bridge that. Adam, maybe you have some ideas. Well, I think I'm observing what you're observing.

I think for, I'm assuming, Rico, that the documentation sites you've got out there for like RSJS is homegrown. Is that homegrown or is that something that you pulled from somewhere else? Yes, it's homegrown. It's powered by a project called DocPress, which a couple of contributors have helped me put together. And I mean, just like Jared said, I think that, you know, you come into your documentation, your sites, even InProgress was a very aesthetically pleasing site. I think what you see there when you have good design is not so much like, oh, because of the good design, I love this project.

It's more like the thoughtfulness, the care, the intention is what comes across in those moments because if you go to somebody's project that not using the default github pages designs is bad it just you know there's nothing wrong with that at all it's it's a great starting point and it may be a great forever point for some projects but going above and beyond like rico has shows like this person has a significant care for how this project is perceived to the community so it's like it deserves an extra look I see maybe not even just care but also skill like just to be blunt like like because that's I guess my the the sentiment that I'm displaying is like even though I do care a lot and I have the thoughtfulness and maybe even my API design is spectacular and I'm good at things like that or the CLI interface is really easy to use. So I have like user experience, but I just can't put together the design.

And I'm just using me as a proxy for people who are in this particular situation. And maybe in that case it's like, well, just use the GitHub pages default theme and just rock your API design right up front there. But Rico definitely has a design skill that I guess I'd just say is enviable. Yeah. I like it. I want it.

I want it to be mine. Very enviable. So you mentioned FlatDoc. I didn't look to the details further in this. So this is powered by FlatDoc is the fastest, as you say, in your sales process here. The fastest way to create a site for your open source project. That essentially is a JavaScript framework that fetches the pages, like markdown and stuff. But then you also have this theme option as part of this. We'll get probably into it further, but maybe before we hit the first break,

give us kind of a tee up to this one. And also DocPress. There's lots of stuff moving here. FlatDoc, DocPress, tee us up. DocPress is a very small library that basically takes a bunch of markdown and makes a website out of it. It's not a new idea, but it is an implementation that I did

and trying to make it in a way that is very simple and extensible. There are other projects that do the same thing, but this one's mine. Anyway, a couple of sites that I run, like rscassist.io, have been built with the help of DocPress. And DocPress itself has been built with the help of some other contributors, which is very, very nice, because they also started using DocPress in their own sites.

Gotcha. When you said that before, I thought I heard you say something doc, and then when I looked at my notes, I saw flat doc, and I made a mistake. So it's DocPress, and then you also have flat doc. So they're completely different projects, obviously. Are they similar in any way? Yeah, they are similar in the sense that they make websites out of documentation. But the way they do it is a little different.

A flat doc is more oriented towards things that are pretty small, things that can fit into one page, and Jockfrizz is more for things that would fit into more pages like a small book or an API documentation. Interesting. I think in that regard, you're definitely using your design skills for the greater good here because you create something like flat doc, which is a very nice looking theme, and it's responsive and all these

things and you can just use it for your project. And so in that sense, you're taking your design skills and allowing them to transfer to others. So there you go. You can have those enviable skills of Rico Santa Cruz on your project. They're mine. I will not use DocPress every time. I love the design. I mean, it's definitely, it's perfect for docs, in all honesty. I mean, I think that it's clean, it's simple, and it focuses on the necessary content. So I like it. Very good job.

Thank you. Thank you. There are a couple of other projects out there that do the same thing and probably even better. Like, say, for example, Gitbook is very, very similar to DocPress. And it's one of the things that really interests me as well, that I might be making a couple of things, but feels humbling to be part of that collective effort of many people across the globe, just honing an idea, making implementations of it. And even if other people would be using other projects, like you would be using Gith book instead of doc press. You know, I kind of feel like I still had some part of it in some way into shaping the idea of what,

say, a documentation site generator would be. This episode is brought to you by our friends at Linode. Everything we do here at Changelog is hosted on Linode Cloud servers. Pick a plan, pick a distro and pick a location and in minutes deploy your Linode cloud server. Duel worthy hardware, native SSD cloud storage, 40 gigabit network, Intel E5 processors, simple easy control panel, VMs for full control running docker containers, encrypted disks or VPNs, 99.9% uptime guaranteed, 24-7 customer support, 10 data centers, 3 regions, anywhere in the world they've got you covered. They also have cloud.leno.com, which is an open source, single page application. Find that at github.com slash leno slash manager. Plans start with 1GB of RAM for five bucks a month or high memory

plans at 16 gigs. Head to linode.com slash changelog. Get four months free with their basic server. $20 in hosting credit. Once again, linode.com slash changelog. so Rico the thing that I knew you for prior to KZAP telling us we should interview you is your cheat sheets which I'm a sucker for a good cheat sheet. I love learning by example. I love that TLDR pages project that blew up. We blew that up on Twitter maybe a month ago. Adam, remember that one where they're basically saying man pages are too dense and

difficult to read. I don't think that's necessarily true, but they hide the examples at the bottom. That's absolutely true. Let's have a new thing. That's just examples. I don't think that's necessarily true, but they hide the examples at the bottom. That's absolutely true. Let's have a new thing that's just examples. I love all that. And I've enjoyed your cheat sheets for some time. Tell us the story of this,

because you finally have like a proper devhints.io. It's like a thing now, but these cheat sheets have existed. So give us the backstory on this project. Right. So it used to be just a humble repository with a bunch of markdown files. So if I have notes on something that I'm learning, I just put a markdown file with

the same project name. And for some reason some people started having some people started starring that project which is very strange uh it basically had a read me of two characters which is a smiley face just to really drive into point that you know i wasn't really expecting much of it and it started getting traffic, and I decided to put it online on my website, on my personal domain. And I didn't really notice for a while. When I came back to Analytics, it turned out that it was gaining traction, and people were starting to actually link and starting to tweet about it. And I figured it's probably time that I make it into a full-blown website.

So just very recently, I launched devhints.io, which is basically the same thing as my old cheat sheets website with a shinier coat onto it. And basically a domain name where you could just type in devhints.io slash something, like slash React or slash ES6 or whatever it is. So that makes it a lot more convenient because I would sometimes give my cheat sheets to my colleagues

and it was such a long URL to type, like, my domain name, Rico, S-T-A-C-R-U-Z dot com slash H-E-C-H-E-R-U-Z, so on and so forth. Yeah. And now we just have devins.io slash react. It's really nice for just pointing somebody to, you know, slash sass slash react. And, you know, for those just looking for a refresher on certain things, like if you go to slash sass, you're doing sass style sheets,

very easy to be like oh that's how you do variables or oh that's how you do nesting and that's how you you know implement and extend or whatever like that's really you know not every language is the same so like you can probably rinse and repeat that for most of the different languages but like if you go to react for example you got different components and some of them are more complex than others and the you know the the design is pretty awesome but you can go there very easily and uh just point anybody to it and obviously and and they get a kind of a bird's eye view of like what you can expect with certain common implementations in the language oh yeah and uh i do like how it's very bite-sized.

Like you could go to any cheat sheet in Dev Hints and digest and soak up everything in a minute. And one of the things that I'm trying to do is run a Twitter account where I just kind of tweet a random Dev Hints page with a random snippet. Just kind of a daily TLDR sort of thing. That's a good idea.

I like that, especially now that you've got 280 characters to work with. It gives you a little bit more room for shorter code examples or at least something that can be bite-sized in a tweet with maybe a value proposition and a url yeah yeah i mean just as a side note i think the 280 character limit has been quite a nice change for accounts like that aren't personal accounts like that's fine too but i feel like our change log account okay our go time account these have room to breathe especially when we're like tweeting about a show, you can actually put some stuff in there now.

Whereas before it was like you had to use emoji because you didn't have enough characters to represent things. And it was like squeezing every last character. So yeah, another great example is we can fit, if you're tweeting out some TLDRs or some tips and tricks, you can actually fill a little bit in there. I think it was actually, at first I was like, what?, some tips and tricks, you can actually fill

a little bit in there. I think it was actually, at first I was like what? And then I was like, eh, not bad. Not bad at all. I think you, you know, I'm not sure if everybody knows this either, but like I literally do not touch our Twitter account. Aside from the occasional response and or direct message

response or something like that, Jared handles it all and i'm always uh super impressed with his abilities to like be tongue-in-cheek with certain things and just funny in certain things and just you do a great job of using those 200 280 characters really wisely because some people couldn't like just go on and tangent you know but or even overuse the characters but to like use them wisely use them to give the tweet more room to breathe as you said oh thanks a little sidebar there you're welcome buddy thank you so rico one of the things that i did back in the day when I was first learning Vim specifically was I searched for cheat sheet PDFs and I would print one off and I would have it at my desk next to me.

I remember also when I was learning Ruby. And I would just say I would have loved, loved, loved to have this website back then because this is exactly what I was looking for. And they were impossible to find. And the ones that you found were either abandoned, or the person that put the PDF together wasn't very good at design, and so it was hard to read them and stuff. And so I'm basically just maybe complimenting

you on this project, but also wondering if these are meant to be printed, or if you've put thought into print style sheets and how all that would play out. A couple people were asking me that, but it actually isn't that easy to implement for dev hints. I'm hoping to get print style sheets in there sometime, but the time being, we don't have

that. Maybe I can ask this then. Do people really want to print these, Jared? I mean, the day you mentioned was several years ago. Probably like 12 years ago, but I don't know if that... Well, I gave you several to not make you so old. But anyways... People still print stuff, right?

Do they? Like reference. Don't you? Rico, when's the last time you printed something? When I was renewing my passport. I needed to print some forms. See, exactly. The only time I print things is when I'm returning things to Amazon.

I would like to put it on a shipping box. That's right, yeah. I don't, I mean, I will fight somebody over printing something. I'm saving the trees. No, I'm just kidding. I just hate printing. So I just wonder if, like, is anybody asking you to print these things? Just me.

Well, you said a couple people. Two people. Okay, two people. Anyways, I'm just playing the devil's advocate here. I was just like no i get it people and i i agree that printing is on its way out i think when there's what i feel like if you have if you're trying to learn something and it's complex i mean if you look at all those different things you can do in vim you can i'm still learning them after 12 13 years of using it and And you want to commit it to memory. Print it off.

Even, heck, if you're anal retentive, laminate it. Lamination is great. Maybe it's because we're schooling around here. Rachel loves laminating things. And it's nice to have a nice hard reference. And have it there at your desk. Physical thing.

You can reference it. You don't have to flip your tab back and forth. There's value there. There's value. I can't disagree with that. And can reference it. You don't have to flip your tab back and forth. There's value there. There's value. I can't disagree with that. And I won't. But don't print these because they won't look very good. Tell us about the technical implementation.

You mentioned they were markdown files. I'm assuming that there's still a GitHub repo. Is it collaborative? How are they edited? Who creates these cheat sheets? Tell us all that stuff. Yes, it's collaborative.

There's more pull requests than I can manage. And it's like what you said, it's a repository with markdown files in it. And we got Jekyll, which is GitHub Pages' default blog static side engine. And at the moment, that's working pretty well for us. So what that does is we just push a bunch of markdown files into a repository, then GitHub Pages would take care of turning it into a website with a bunch of templates.

And that's how it is, pretty much. There's some aspects here that it feels interactive. I mean, maybe it's just all in HTML search. The first thing you hit is the search bar. Is that just filtering content on the page? Or is there no back end here? Yeah, that's a very lazy implementation of search. As you notice, it's not very good,. A search, as you notice, is not very good,

which is something that I'm hoping to push some improvements on sometime next year. So it's all static, all rendered. Keep it simple, man. I like that. Absolutely. There's no server-side component or anything. So 17 open pull requests. This is a new cheat sheet. Cheat sheet added for PM2, added cheat sheet for Bulma, added C Sharp 7, create Angular 2. I mean, these are almost all new cheat sheets or changes to existing cheat sheets. Is this a place, and that's the pull request,

there's 181 issues, so there's probably other suggestions and bugs and whatnot, but are these places where you would accept help if somebody were to come through and say, I'm Cheat Sheet Master, or is that something you like to keep close to the chest? The management of this seems like an interesting aspect of it. Oh no, definitely. It's not something that I'm keeping to myself. And there's a lot of contributions into dev hints.

A lot of people would contribute anything from small typo changes to new sections to totally new cheat sheets. And I totally welcome that because I can't write everything. If you notice, you've mentioned, I think, 180 issues. It was probably more than when I last checked. And most of that are people requesting, oh, could you put a cheat sheet for whatever their favorite library or language is? And sometimes I don't even know these languages or libraries, so it would be very helpful if other people could put together something,

put together a pull request. Well, you are not lying, because I'm looking now at the open issues, helpful if other people can put together something, put together a pull request. Well, you are not lying because I'm looking now at the open issues and they're almost all cheat sheet requests. Mercurial, Polymer2, ElmRust, MarcoJS. One says app name here. I'm guessing they just didn't actually figure out they're supposed to put the app name right there. But actually two of them. I think something interesting too jared is something that comes a little closer to the hacker heart of changelog.com is joseph

a limb contributed a update to the phoenix cheat sheet which was to use proper directory structure for phoenix and so i'm kind of this language creator the somebody who is playing heavily in elixir and phoenix say oh uh let me help you out here it's already in place somebody's already contributed but something's been updated and somebody like jose comes comes by and says oh let me send a pr for this that's awesome it's actually pretty interesting uh as you said jose valim is one of the people who put together Elixir as a Language. Phoenix was the project of someone else, Chris McCord. But anyway, I worked with these two guys before because when they were building Phoenix and Plug and their error pages,

they took a template that I did, started with that, and I basically told them, hey, why don't we build one from scratch? And I built something and contributed to Plug and Phoenix with their help. And I was just really surprised to see Jose Valim's name in a very recent PR in Dev Hints, because I didn't tell him anything about the project. And I was just really pleasantly surprised to see like, hey, you stumbled upon my new project. So that's pretty cool. Any pressure to change the name?

Considering it began as Cheat Sheets and now it's Dev Hints, any concerns there around branding or just name collisions well i didn't really want to call it like rico's cheat sheets.com you know it still says rico's cheat sheets when you when you hit the dev hints home page yeah uh yeah the main idea behind getting a domain name is to get people to be able to type it from memory. So I just tried to pick something that was easily rememberable and not taken. So I settled with dev hints. I didn't notice that, Jared. It does say that. It's the headline, Rico's Cheat Sheets.

Yeah, I didn't want to lose the homegrown feel of it because at the end of the day like 95% of this is stuff that I typed out and I'm not going to deny a lot of these cheat sheets have a bias towards some approaches that I feel would be better I mean they are kind of opinionated in some way. So I just thought like, yeah, maybe I'll keep that headline in there. Yeah, just to signal to people that, yes, this is community. Yes, these are all open source, but these are Rico sheets, all right? I like the one thing I was noticing too was the process of writing a markdown file which can be kind of tough if you got to write or if you gotta hand type a table like you may have to for i i believe it's the

zsh cheat sheet so if you go to dev hints.io slash zsh you will see what i'm talking about and right there at the top and if you look at the Markdown version of this, it's expressions and it's, you know, luckily we have essentially sites online that make it a little easier to actually, you know, create a Markdown table because it's fairly cryptic to read as Markdown. But rendered, you've got this beautiful looking table, but it's essentially, you know, a heading

and some supported, you know, content that gets designed out. Any, you know, kind of considering how simple, I guess, the, you know, the style guideline may be, you know, in terms of like how you implement a new cheat sheet. Have you had any pushback, Rico, or any actually have a stock ad? I know you have the contributing document, but is there anything that says more clearly like, hey, when you create a heading that's H2 in Markdown and follow it up with a table or a code example, expect that to fall in line or fall into this grid and it'll look beautiful on the site. How do you instill good guidelines for people to follow?

Good question. There's actually a cheat sheet for that. Is that right? Oh, snap. Is it called guidelines? It's called cheat sheet dash styles. And I think it's linked from the contributing.md file. I see it there.

I'm looking at it now. Okay, nice. Okay, so you got variants, you got each three sections. Interesting. Yeah, it's not like super well thought out kind of documentation, but it seems like it does its job for now. A couple of people are submitting their cheat sheets

and I'm actually very, very pleasantly surprised to see that they all look good without me helping them out. Well, I think, you know, I mean, it's a Jekyll site, so that's fairly easy, aside from maybe, say, getting the right Ruby in place or gems in place, that's still some things people trip over.

Aside from something like that, like getting Jekyll to run is fairly painless, but being able to see even the online documentation, like this URL we're looking at, which is devhins.ios slash cheat sheet dash styles, and comparing that to its counterpart in the repo, and you can kind of look at the markdown and the raw markdown and say,

okay, well, this is how it's going to look once I ship it or once it's rendered on site. It's good. Yeah, so what I really like about how everything is set up in DevHints is that I tried to make it so that it's optimized to authorship, a very easy thing to do. I basically just want to go from ID to cheat sheet

just by opening Vim, typing a couple of things out, and to go from ID to cheat sheet just by opening Vim, typing a couple of things out, and then suddenly it's a cheat sheet. So, like you said, it's all marked down. There's not much special about it. Looking at this, I can't help but think back to

the good old days, if you guys will go with me, of Defunct's cheat tool. Do you guys remember that? I do. I don't know where you go if you were around back then, but Chris Wanstroth, I can never say his last name. Wanstroth. Wanstroth, Defunct. Of course, a well-beloved hacker and one of the co-founders of GitHub. Used to have lots of really awesome open source projects.

One was called Cheat. And Cheat was a command line tool that did basically exactly as it described cheat sheets from the command line where they were text only and you type cheat rails or what have you. And it would pull them right there in for you. And this is very much in the same vein as that. And so I can't help but think, when's DevHint coming to my command line? That's what I want. I want cheats in my command line because Chris's thing is long closed down. And this is maintained and it's got great design

and tons of information. Are you bringing it to the command line? Interesting that you mentioned defunct cheat because that was one of the things that I was also referring to and one of the things that was I guess an inspiration for dev hints. And like I said, it's not been

maintained for a little while. I don't think the website's working right now. But yeah, this is one of the things that I was referring to when making dev hints and for the command line that's interesting i've been actually thinking about this like what's the best way to bring it to the command line and the way i do it at the moment is you just use a command line browser like w3m or links and dev hints is mostly just markdown and it's mostly

just simple HTML they come out pretty great in the command line as well well that's a good hack for now I think ideally I'd love to just type like hint es6 and then have like a actual in curses based rendered thing that's like native

but I'll try that here so you can just use actual in-curses-based rendered thing that's like native. But I'll try that here. So you can just, I'm just going to use links and just put a full URL in. Slash ES6. Should I allow cookies? Oh, man. I'm going to allow cookies. Hopefully that's a, yeah, not bad.

Got the pagination there. I haven't used links since I was a kid, Hopefully that's the... Yeah, not bad. Got pagination there. I haven't used links since I was a kid, so that's cool. Good idea. I like that. And you just have it handy? Links is just handy for you? Links.

L-Y-N-X. It should be default on most Unixes. Oh, is that right? Okay. I didn't know it was baked in. I was like, I wondered if it was something you had to like apt-get or homebrew. Maybe. It's to like app get or, you know, homebrew.

Maybe it's actually in user local bin. So maybe I homebrewed it. I don't know. Hmm. Okay. But what was the other command line based browser you mentioned there, Rico? W3M. I don't know that one.

That's a new one to me. W3M. Is that a newer one or older? It's newer, but it's still pretty old i remember using it back when i couldn't get x windows to run in a linux so it's been out there for a while all right that's an interesting concept too that to to use a text-based browser you know and the command line implementation of that to just essentially browse a fairly simple markup site. The markup for this site isn't very complex.

It's a good, I would say it's a good temporary. I'm not sure it'd be a good long-term, but I could be wrong. Some people just demand more, and if you don't give it to them they'll upgrade it on their own. One thing you could do, just like how could you get it done

really quickly, even if you weren't Rico, you're just like you know what, I could hack a command line tool around this is are the markdown files exist on the dev hints domain or is it just the rendered HTML? It doesn't on the domain,

but it does on GitHub. It's all just a wrapper. So you could just fetch it by HTTPS, I guess. Yeah, you could just resolve it just from the, because all the naming is very conventional. This is similar to how we do our transcripts, where all of our names are basically conventional around, you know, show title

slash slug dot md, what have you. So you could just write a little wrapper that basically goes to GitHub. You type hint and then es6, and it just resolves Rico's repository, the raw version of the markdown, and then parses it and then displays it in some sort of good fashion there.

Yeah, all these markdown files are in the root, so. Easy peasy. Right? Somebody do that. Somebody do that. Tweet at us. Let us know about it. fashion there. Yeah, all these markdown files are in the root. So easy peasy, right? Somebody do that. Somebody do that. Tweet at us. Let us know about it. Any last thoughts

on dev hints before we switch subjects on you? Well, do check it out and tweet about it and contribute something if you see something that

you could edit or something you could make for it. And yeah. Any call to creators out there that are like you know my thing has to be in every hinter what's the best way i guess you probably just my thing has to be every hinter who thinks that i would i would imagine that like if i'm if i'm the creator of Elixir, for example, I would want to make sure that all my hints are in your base. You got to give Jose credit, man. He's everywhere.

He is everywhere. Yeah. Yeah, so what's the best way to get your project's cheat sheet in devhint.io? A pull request. A pull request. A pull request. But you got a lot of open pull requests. How do you float to the top of the pile?

How do you get an easy merge button? Good question. I'm just trying to clear out the pull request queue right now, actually. While you're on the show? No, I mean... I was just seeing they're going away right now. What's a good call to action, actually, is to say, you know, I'm imagining that a lot of these pull requests are not so much Rico required, right?

Like, this is something where if you care about others getting leveled up, then lend a hand to clearing out some of these issues, or at least giving some feedback, additional eyeballs, so to speak, on, yeah, Rico, this looks good. You should merge it. Yeah, definitely. And that doesn't just go for my project. I think that goes for every open source project out there.

One of the easiest ways to contribute to something is just lend a few eyeballs into whatever's out there, a couple of issues, a couple of pull requests, give you a review or give your thumbs up absolutely just maybe give me a quick moment to give a shout out to chris chris 48s who has contributed greatly on our transcripts by basically doing that he was just doing some transcripts and like you can fix some unintelligible words or add links or whatever. There's issues.

Sometimes proper nouns don't get transcribed correctly. And I gave Chris the commit bit, and now he's actually merging other people's requests and helping out quite a bit. So thanks, Chris. And Rico, maybe something that you could look into is find somebody who's excited about Dev Hints and helping out in the PRs and

then, you know, hand them the keys and let them manage those pull requests and take the, take a little bit of the weight off yourself. Oh yeah, absolutely. I have to say something too, because I saw the two PRs get closed early this morning, and they both had, you know, like, thank you for your changes. They're live here. Very, you know, very our style.

You know, very intentional, very clear. And Chris, thank you so much for that. I mean, to wake up to some pull requests being merged that we didn't have to manage is very appreciated. So it's nice having that burden spread. That's really sweet. This episode is brought to you by Google Cloud Platform and their awesome weekly podcast where Google developer advocates answer questions, get in the weeds, and talk to experts, customers, and partners about GCP. Here's a preview of episode 111 where Mark Mandel is asking Sam Ramji about products he's passionate about in

the future of cloud. Are there particular technical products that we have or potentially may have in the future that get you really excited? Anything you're particularly passionate about right now? Oh boy. Just pick one. I was going to say clearly I'm not a very passionate person. I'm really lucky I get to care about all the things I'm doing. There's a lot of real interesting things happening in terms of how we take

code, which is a developer's set of intents and turn it into running production systems that developers and operators can both collaborate on. There's a whole chain of technologies there, both first-party technologies and third-party technologies. Third-party like Spinnaker that we've gotten into.

It's an open-source project that was started by Netflix, and we've gotten really involved in it. It's a really nice way to do multi-cloud computing. And all of these things really need to come back to giving developers control of exactly how they want their code turned into an artifact like a container, how they want it structured into services and pods, and where they might want to run it. So I think part of what brought me to Google was this core belief in open hybrid cloud. When I left Cloud Foundry, I had spent two years committing all of my heartbeats to putting technology back under the control of the companies that use it rather than the companies that sell it.

And part of what brought me here was Brian Stevens said, you know, our mission is to be the open cloud. I said, you must be kidding me. That doesn't make any sense. Every hyperscale cloud provider is clearly an ambitious monopolist. Not at all. Right. So when we look at this. So if you're looking to move to the cloud

or generally interested in deeply technical cloud-focused conversations, check this podcast out. It publishes weekly and you can subscribe in Apple Podcasts, Google Play, Stitcher, YouTube, and more. Head to gcppodcast.com and look for the big subscribe button

at the top right-hand corner. Once again, gcppodcast.com. And by GoCD. GoCD is an open source continuous delivery server built by ThoughtWorks. GoCD provides continuous delivery out of the box with its built-in pipelines, advanced traceability, and value stream visualization. With GoCD, you can easily model, orchestrate, and visualize complex workflows from end to end. It supports modern infrastructure with elastic on-demand agents and cloud deployments. can easily model, orchestrate, and visualize complex workflows from end to end. It supports modern infrastructure with elastic on-demand agents and cloud deployments. And their plug-in ecosystem ensures GoCD will work well in your unique environment.

To learn more about GoCD, visit gocd.org slash changelog. It's free to use and has professional support for enterprise add-ons available from ThoughtWorks. Once again, gocd.org slash changelog. All right, Rico. So a couple other projects that you are up to. We mentioned them. We were talking about your design and your different documentation-based generator tools. And you have RSJS, which is a reasonable system for JavaScript structure. And then you have RSCSS, which is, you can guess it, a reasonable system for CSS style sheet structure.

So have opinions and are willing to lay them out there for people, which is always appreciated when people have well thought through opinions. Tell us about these two projects, why you decided to put effort into these, and really the message that they're trying to send. Right, so the first one out of the two is RSCSS. That came first, which is, like you said,

the reasonable system for CSS style sheet structure, which, by the way, coincides with my name's initials. Anyway, so the way this was born is we were just doing things at work. We were just making CSS the way we usually do. And we just kind of felt like there must be a way that we could standardize the way that we do things. So basically, RSS is a system that grew organically with us doing CSS one way and then thinking, oh, let's improve it this way and so on and so forth until it became RSS. So at some point, we just kind of felt like, how do we get new hires to absorb all this knowledge that we have with how to write CSS?

So I figured like, okay, why don't we just write some guidelines that we could show to anyone? It's a very, very small document. It's something that you could read through in 30 minutes or less. And that's basically how RSS was born. So anytime that someone would ask, like, how do you guys write CSS? It goes, oh, just check out rss.io. And the way it grew is it was out of our frustration of other CSS structures out there as well. Like a very popular one out there today is BEM or block element modifier. And it does its job very well at the expense of being overly verbose. At least that's how I and some of my colleagues feel about it.

So our CSS is kind of a middle ground wherein we try to take the ideas of writing modular atomic CSS, but trying to make it so that it's not as verbose and not as something that would be more friendly to your fingers and with less typing involved. So we did a show recently with Adam Morris about tachyons and what's it called? Functional CSS, Adam? And so this whole movement, I'm familiar with

BEM as you mentioned. There's other ones like OOCSS and what's the other one? SMAX maybe? I don't know. There's so many. But would you classify your system as kind of like BEM Light? Or you said it is atomic and modular. Is it about components? Maybe just give us some of the highlights of what you think are good ways of doing it without we don't go through every particular aspect but maybe high level all right good question so when we talk of atomic s or modular css it's not

necessarily conventions or a way of doing things but it's an idea of how you build or you want it lottery which is you have two things and compartmentalize components and there are things you mentioned like BEM and OCS s and smacks and RSS itself are ways to make sense of you implement this idea of making things modular and componentized and how do you formalize them into naming conventions and and how you write your class names and such and yeah in a sense you could say that rss is kind of like bem light in the sense that it's to solve very similar problem with something a little less verbose but yeah it has a it's less feature rich than them but at the same time i think it's a very welcome uh i think it's good that it is that way because it's easier to write okay and it

definitely seems like i'm not sure if i would call it bem light though but uh because it doesn't have the underscore i don't you know identifiers and stuff like that some of the key attributes that come with bem unless i'm haven't gotten far enough into the guide yet, but it seems less framework and more like guideline, I guess. And I think you even say it in your documentation where it's not a framework. It's more like, this is kind of what we do that works for us. And maybe you would like it to. Exactly. I think the components, you know you're being being very

specific where you say a component will be named with at least two words and then you know obviously elements are inside those so we're gonna name this with one word and we prefer to use the child attribute for these reasons you know uh the child selector wherever possible that's i mean i think possible. That's, I mean, I think you're stating some of your core reasons for it and giving visual examples. And I also have to compliment you on doing a great job of using readmes very well. Like this is a great example of a project using a readme very well to sell it. As we said in the first part of this, of this show, which was, you know this show, which was you give an introduction, what this is, what this isn't, and you're greeted with a continue link, and then a continue link from there, and each step just takes you a little further into essentially navigating

GitHub readme throughout the project. Pretty cool. Thank you, thank you. One thing you have here, which I love when people do this, and a lot Thank you. Thank you. I love when people are presenting an idea or a system or something that they believe is potentially good or good in certain circumstances. And preemptively or perhaps maybe due to feedback, they list like here's what people here's are the here are the downsides. Because so much of what we see is like this is a panacea. This is a silver bullet. This is the best way ever. And we know that there's tradeoffs and there's pitfalls.

And so I love that you have those clear and available to anybody who's looking for them yeah uh one of the things that i also like doing in the same idea is whenever i make a project and make a read me for it i make sure to link other projects that have a similar goal to what I'm doing and mention how mine is different. Like you said, there are a couple of people who would be writing things in a way like, here's our solution, here's why it's so great. but they kind of fail to go to the side of what about other projects? What do they do that you're not doing? Or what are other solutions that are out there

that are different from what you're doing? I think when it comes to CSS, many of us are like, just give me some sort of system. I just need something, because the Wild West leaves me in a terrible position. But having a system in place, at least then we can all follow a convention and live with the ups and downs of the particular system.

With JavaScript, it's way more flame wars. And so people, I mean, that's just in my experience. With CSS, we're like're like okay this could be better than BEM or worse I don't know but it sounds cool and it's like JavaScript all of a sudden now you're now you're then this is fighting words so you have rsjs which is a reasonable system for JavaScript structure and um you know it doesn't have it you know it's living off of ricosantacruz.com so it doesn't have its own domain like the other one does.

And you said the other one came first, so I'm wondering where you're at with RSJS and if people have given you the feedback about it that probably I'm expecting will come if it hasn't yet. Right. So we build

Rails apps at work. We build Rails apps and we write a bunch of JavaScript for those Rails apps. And one of the things that we couldn't really figure out is like, how do we organize everything that we write? How do we organize all those JavaScript files? Because Rails doesn't have all those conventions, it just gives you a file like application.js says, like, put your JavaScript here, which is not very helpful. Anyway, so again, just like RSS, RSS is a bunch of guidelines that we had built organically based on what we thought worked, what we thought didn't work. And it's kind of an iterative process until we settled on,

okay, this is how we kind of think about it. Now, it's not like something that you could use on everything, because obviously there's probably so many ways to write your JavaScript. Someone who would be writing a single-page app would be doing things a little differently than someone doing a more traditional Rails app. So anyway, this is one of the ways that we try to manage our JavaScript in an app that is a bit more traditional. And I just kind of thought, why not write it into a small document as well? So just more formality into the way we do things.

Before we ask a couple more questions, I want to go back into RSCSS. Because, Jared, you were mentioning the pitfalls, apprehensions, and other resources. And I have to say, I clicked on those links, and I found them, and I got lost. And I have to say I clicked on those links and I found them and I got lost. And I loved it. But you got lost in the other resources or where'd you get lost? In his resources. And so I want to make it clear just for those listening, thinking like, OK, how is this close to BEM? It's not BEM.

It is BEM. You give a great example on your other resources section where you say BEM is nice but some may be irked. I think you mentioned it's verbosity in comparison to say maybe your short form which is very BEM-like I guess to say except for you're essentially giving an example of how BEM works or B-E-M or however you pronounce it. I just say BEM because it's easier. And you're sort of given a component example

of how it would work in BEM and how it would work in using your conventions. So I like that, that you share that there. So we'll link that up in the show notes, but for those listening, can you kind of give us a verbal walkthrough of that to some degree? Because with BEM, you might say for a component which has to be two words,

site search in this example using a hyphen between the two words, and then you would say, you know, if you had some sort of variant to it, if it was full or if it was partial or if it was minimized or something, then you might say, you know, put the class again, site search dash dash full. In the case of your way, you would just simply the class again, site search dash dash full. In the case of your way, you would just simply have one class site search and then a modifier class of just dash full. And then beneath that, anything that's inside of that component would not have site search again. And then underscore underscore, if you're all following me, you just simply have the one single keyword which is part of your description

I think that's kind of interesting because it does that's where I kind of got tripped up like when do you include the underscore underscore and when should I not so coming back to your using child modifiers or your child selectors and then this syntax now it is a little bit more clearer to me yeah and one of the things that I wanted to emphasize and then this syntax, now it is a little bit more clear to me. Yeah, and one of the things that I wanted to emphasize with RSS is you just write class names as you probably would have when you were starting to learn CSS. So you wouldn't have things like underscore, underscore, dash, dash,

and you wouldn't have to remember where an underscore goes or where a dash goes. That was the hardest part of Ben for me, honestly. I liked it visually, but practicality of it, it made, did make sense after I went away and came back. I was like, where does this go again? How do I resume building out this

component? That kind of thing. Yeah. That's one of the reasons why we wrote it as well. What's the theory on two words? Why two words? It's just a way to differentiate itself from elements which would have one word.

There's not really much science to it. It's just a way it's just a convention that we could implement so that when you look at a class name you know what it is. It's two words, oh it's a component. It's two words, oh, it's a component. It's one word, oh, it's an element. It starts with a dash, oh, it's a

modifier. And then coming back to RSJS, this is very similar to like, you're obviously trying to accomplish a similar goal, which is, you know, hey, this isn't a framework, this is kind of a guideline on how we write JavaScript.

And also, specifically for non-SPAs. So when I was talking about a lot of the argumentation that happens, it's usually around how to structure single-page applications. And so actually, this is something that I haven't seen. I have myself what I believe is a reasonable system, which I have never written down, for structuring JavaScript. In these more what we call classic server-side rendered, what I believe is a reasonable system, which I have never written down, for structuring JavaScript in these more what we call classic

server-side rendered what DHH lovingly calls JavaScript sprinkles types of applications. And I've never seen anybody else I've never seen anybody, I can't say anybody else because I've never done it, I haven't seen anybody write down

a system for those, similar to how we have ideas around how to do them with a single page app. So that's interesting. Thank you. That's precisely why we wrote it, just to get things formalized into an actual document, which

are probably just kind of knowledge floating around between the team and now we have a document that we can refer to. I think something that's admirable with the type of developer, I assume you may or may not be, Rico, is that it's one thing to be a developer that gets it and can implement it themselves. It's another thing to be the kind of developer

who can then distill that into coherent documentation. That looks good, is publicly accessible, embraces the idea of open source and community, and shares that with the world. That's a whole different kind of person, and that's you, and I appreciate that. Because we need people like you to sort of distill down the trial and error stuff that, you know, all these bloody knuckles. So many people have bloody knuckles, but they don't share why or how they avoid that in the future. And you seem to do it so well. Right. Thank you. And I'm actually glad that there's a lot more people who are also interested in putting things into words.

I got a lot of developers publishing their thoughts on Twitter, Medium, and pretty much everywhere. I'm very happy to see that people are writing down their thoughts. So with these two projects in particular, since this is the last segment here, is there any community involvement with this? Since this is your bloody knuckles trial and error, so to speak, and it's your guidelines,

how does the community get involved or participate? Very interesting because RSS has been translated in a couple of languages. All of these languages I don't speak, so it's been very humbling to see people just contribute their own translations of it awesome so far chinese uh thai japanese spanish so there's still plenty of language that's out there if you have a native tongue and others can uh learn from from rico's experience that's a great

way to uh to help out. I assume the actual content of the documents is, I wouldn't call it necessarily static, but these are your findings. And so it's not necessarily that you're looking to expand or change unless you all learn something new at your work. Is that correct? Yeah. And in a sense, I would like to think of it as more or less complete and if there's any more additions to it from this point forward

would probably be more clarifications so there's actually a translations branch is that where the translations live? how does this get implemented this translations portion? so if we have somebody listening that's like hey I speak two languages I can probably help out with something, and they want to look at it. How do you go about helping to translate? They could fork a repository, make some edits,

and they could publish their own version of the website. And it's pretty easy. There's a documentation in the repo on how to do these things. Gotcha. So the intention is then for someone to fork it and host their own version of it in a different language? At the moment, yeah. Gotcha. Okay. I'll just say that there's a Russian translation and a French translation

and some other translations sitting in Rico's PR. So there's a theme happening here and I think what Rico really needs is somebody, and maybe more than one person, to just help him out in his GitHub and provide a little bit of, you know, help him grease the skids and keep these projects going because there's activity, there's improvements, there's lots of people who are wanting to help out. And that's a lot for a single person to to handle so if you have some bandwidth and you can help them out there's a lot of low-hanging fruit in terms of ways that you can have a beneficial contribution to the community so i would advise somebody out there to hook up with rico and help them out with some of these prs like that and we'll definitely put the links in the show notes so if you're listening to this the easiest way to do that is to not try to rewind or fast forward and find the link we mentioned.

Just go to the show notes. It's there. Thank you, guys. And it goes not just for my projects, but for pretty much everything you use in your everyday life and your open source life. All projects and GitHub could use a set of eyes. Just, you know, look through the comments, look through the issues, and look through the pull requests and leave a note when you feel like

you got something to say. Absolutely. Well, Rico, thank you so much for your time today. And just, again, I'll say it again, just sharing, you know those those uh trial and errors the the bloody knuckles the you know the guidelines back to the community there they're so important and if you're out there and you're listening you've and you've got rico like type things in your brain and you haven't shared it yet the first thing to do is

what rico create a repo and share it right just tweet Just tweet about it. That's the advice we're giving with create open source and share it. Is that what we should share with the rest of the community? Absolutely. Just put your stuff out there. Just put it out there and tweet at Rico. We'll link his Twitter up in the show notes and whatnot and he'll retweet it for you because he's that nice.

Absolutely. All right, Rico. Thank you so much for your time today, man. Appreciate it. And thank you so much for your time today man appreciate it and thank you so much for having me no problem all right that's it for this episode of the changelog if you enjoyed this show you know what to do share with a friend don't be shy and while you're at it head to changelog.com and see what's updated we got a brand new site out there you're gonna love it do yourself a favor please check it out. And thank you to our sponsors for the show.

Command Line Heroes from Red Hat, Linode, GCP Podcast, and GoCD. Bandwidth for Changelog is provided by Fastly. So go to Fastly.com to learn more. Air Monitoring is by Rollbar. Go to Rollbar.com. And we host everything we do on Linode cloud servers at linode.com slash changelog. Check them out. Support this show.

And this show is hosted by myself, Adam Stukowiak, and Jared Santo. Editing is by Jonathan Youngblood. Music is by Breakmaster Cylinder. And you can find more episodes just like this at changelog.com or wherever you subscribe to podcasts. See you next week. Thank you.