Special Guest: Kyle Holmberg & Alex Regan In this episode, the panel talks with two guests Kyle and Alex who work together in opensource. Kyle is a software engineer at AutoGravity interested in full-stack web development, graphic design, integrated systems, data visualizations, and soccer. Alex writes code and works with Parametric Studios, and he also loves puppies. Check out today’s episode where the panel and the two guests talk about the different frameworks and contributing to opensource. Show Topics: 3:03 – We got together because Alex mentioned his project. He was looking for something to get up running nice and easy. Boot Strap 4. That is a nice choice and I was contributing as a core team member at the time. He started with how do I get started with Boot Strap Vue. At the time I asked how do you do this...? And that’s how we got started. 4:03 – Guest continues more with this conversation. 4:30 – Chris: How did you start contributing within your company? 4:44 – Guest: There is a lot of autonomy with the last company I was working with (3 people there). I needed more fine tooth hooks and modals. Someone says X and you try to figure it out. So I was looking at the transitions, and there was a bug there. They hadn’t implemented any hooks, and I thought I could figure this out. From there, if you want a change I can help out. I don’t know if that change got implemented first. I started contributing some things to the library. I really got involved where someone (the creator of the library said you could be a core member. He took a trust in me. I started a lot in test coverage. That might not be the normal path to take. 6:39 – How long have you been developing? 6:42 – Guest: A year and a half. 7:00 – Chris: Any tips to opensource for beginners. 7:10 – Guest: Yes, having a thick skin. Everyone is anonymous on the Internet. People say things that they normally wouldn’t say in person. I figure if you put something out there someone will correct you. How can I get feedback? If you put yourself out there it’s like: failure to success. That process is what makes you better. 8:21 – Chris: Issues and chat like that. There is a lot of context that gets lost. When you just see the text it may seem angry 8:43 – Guest: I have a tendency towards sarcasm, and I have to save that to last. People come from different languages, and I’m not talking about software languages. English isn’t everyone’s first language. Good thing to keep in-mind. 9:14 – Internet is an international community. 9:22 – Guest continues this talk. Opensource is good to work on to get started with contributions. Especially with Operation Code it’s geared towards beginners; less complex. 10:30 – That is a good difference to show. 11:01 – Question. 11:05 – Guest. If you are a person with a lot of skin in their projects – I take pride in my work – I think if you have that mentality that you will want to submit to every request. Find some way to test every request against a...is this my concern or their concern? Figure out the boundaries. You will make mistakes and that’s fine. 11:54 – Panelist. 12:02 – Guest: Coming up with good interface boundaries for your libraries. 12:11 – Chuck: Once we figured out what really mattered than it makes it easier to say: yes or no. 12:26 - Guest: Conventional Commits. 13:06 – So Kyle what did you getting into opensource look like? 13:19 – Alex: Boot Strap. Operation Code. 15:07 – Chuck chimes-in about Aimee Knight and other people. Serving people and their country. You are helping people who have sacrificed. 15:58 – It is totally volunteer-based. 16:05 – Chris: What kind of questions did you ask Alex? How did you decide what to put in an issue? 16:25 – Alex: I tend to go to Stack Overflow. If it is in regards to a library I go to GitHub. Real time texts. Next.js – I just contributed to this this week. 19:21 – Chris: This question is for either one of you. For Questions and Answers – do you have any suggestions on what NOT to do when seeking help? 19:46 – Stay away from only asking a question in one sentence. There is so much information/context that you are leaving out, and that can often lead to more questions. Reasonable amount of contexts can go a long way. Code samples. Please Google the details for the markdown if it is a huge code. Context, context, context! 20:44 – I have an error, please fix it. Maybe that needs more context? 20:53 – Guest: What were you doing? There is a bigger overarching element. The problem they can see in front of them and what is the thing that you are TRYING to solve? 21:44 – More contexts that can help with a helpful answer. 21:53 – Guest: If someone used some learning tool... 22:13 – Chuck chimes-in. Chuck: It is something different that it could do something that you didn’t expect. 22:47 – Alex: Those are great moments. I love it when Kyle sees... That snowflake of your problem can help with documentation caveats. 23:44 – People are probably copying pasting. 24:05 – It can be the difference between understanding the page and not especially What not to do and what to do – any other tips? Can you have too much information? 24:32 – Guest: I am guilty of this sometimes. You can have too much information. The ability to converse in a real-time conversation is better. That’s my route to go. Maybe your problem is documented but documented poorly. Go to a real-time conversation to hash things out. 26:15 – Guest: If you do your homework with the different conversations: questions vs. concerns. Real-time conversation. He talks about GitHub issues and Stack Overflow. 27:48 – Chuck: My password is 123... If they can duplicate... Alex: Yeah too much information isn’t good. Some places mandate recreation like a JS Fiddle. Like Sandbox are cool tools. 29:32 – Is there a way to do the code wrong? 29:38 – Advertisement. 30:25 – Guest chimes-in with his answer. 31:31 – Question. If it’s opensource should they share? 31:33 – Absolutely. The difference that makes it for me is great. I can spot things that the machine can help me find. One small tip is when you provide code samples and GitHub issues use... The further you go out to recreate the problem there is a high payoff because they can get something working. The big difference is that it’s a huge pain to the person trying to convey the issue. If I do the simple version...I think you have to weigh your options. What tools are out there? Generate your data structure – there are costs to recreate the issue. 33:35 – Chris: 500 files, apps within the app – intercommunicating. All you do is download this, install this, it takes you ½ a day and how does this all work? 34:03 – Guest: You have to rein it in. Provide the easiest environment for it to occur. If you are having someone download a table and import it, and use a whole stack – you can try it – but I would advise to work really hard to find... 34:50 – In creating a demo keep it simple? 35:52 – Guests reply. 36:02 – Chuck. 36:07 – Chris: I learned about your experiences coming to opensource. Anything else that you would like to share with new contributors? 36:25 – Guest: Start with something that you have a genuine interest in. Something like a curiosity light bulb is on. It makes it more interesting. It’s a nice way to give back. Something that interests you. I have not found a case yet that I’m not compelled to help someone. Putting yourself out there you might be given a plate you don’t know what to do with. My learning experience is how welcoming opensource is. Maybe things are changing? 38:31 – Chuck: I have seen those communities but generally if they are there people frown down upon it. The newer opensource communities are very friendly. These projects are trying to gain adoptions, which is for the newer users. 39:17 – Guest: Final statements on opensource. Even if you think it is a small contribution it still helps. 40:55 – Guest chimes-in. It is important to have a platter for newcomers. 41:15 – Chris: I am curious to talk to you about how you’ve written React applications among others. Any advice? What resources should they 41:46 – Guest: Yeah. If you are making your new React application (from Vue land) there are many things that are similar and things that are different. As for preparing yourself, I am a huge fan of this one course. I had been coding (plus school) so 5 years, it’s okay to dive-into community courses. Dive-into a tutorial. Understand the huge core differences. He goes into those differences between React, Angular, and Vue. 43:30 – Guest talks about this, too. 45:50 – React doesn’t have an official router. Vue provides (he likes Vue’s mentality) other things. There is a library called One Loader. 46:50 – Guest: I was at a Meetup. One guy was doing C-sharp and game development. His wife had a different background, and I think they were sampling Angular, Vue, and React - all these different frameworks. That was interesting to talk
VoV 032: “Recursion with Vue” with Kyle Holmberg and Alex Regan | Views on Vue podcast - Listen or read transcript on Metacast
