<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Rob Seaver</title>
    <description>The latest articles on DEV Community by Rob Seaver (@rbseaver).</description>
    <link>https://dev.to/rbseaver</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F208769%2Faec257ed-fc91-4165-b6bb-befc791fdad8.jpeg</url>
      <title>DEV Community: Rob Seaver</title>
      <link>https://dev.to/rbseaver</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/rbseaver"/>
    <language>en</language>
    <item>
      <title>Adopting the Angular Style Guide</title>
      <dc:creator>Rob Seaver</dc:creator>
      <pubDate>Wed, 02 Oct 2019 23:03:58 +0000</pubDate>
      <link>https://dev.to/rbseaver/adopting-the-angular-style-guide-4cm</link>
      <guid>https://dev.to/rbseaver/adopting-the-angular-style-guide-4cm</guid>
      <description>&lt;p&gt;I'm working on building some consensus on my team around coding standards. One thing that has sparked a bit of disagreement is coding conventions around Angular. One of our developers is very much in favor of adopting the Angular style guide for all of our Angular code while the other doesn't think it adds very much value. I'm looking for a compromise (mostly because I hate having conflicts).&lt;/p&gt;

&lt;p&gt;The developer in favor of adopting the style guide believes that it is an essential part of code quality and that it enhances readability. The other developer cares very much about writing clean code but isn't as concerned about focusing on things such as sorting import statements. Both want to deliver great products and write good code but disagree on this point.&lt;/p&gt;

&lt;p&gt;My feeling is that there is a vast array of extensions in the VS Code world (our editor of choice for frontend work) that can help us achieve a happy medium. What are your thoughts on adopting the Angular style guide as a team?&lt;/p&gt;

</description>
      <category>discuss</category>
      <category>angular</category>
      <category>typescript</category>
      <category>codequality</category>
    </item>
    <item>
      <title>Moving to CI/CD</title>
      <dc:creator>Rob Seaver</dc:creator>
      <pubDate>Mon, 09 Sep 2019 12:49:15 +0000</pubDate>
      <link>https://dev.to/rbseaver/moving-to-ci-cd-5hk1</link>
      <guid>https://dev.to/rbseaver/moving-to-ci-cd-5hk1</guid>
      <description>&lt;p&gt;Last week I authored a quick post about moving my team towards CI/CD. I was looking for some feedback from folks, but I think as a neophyte to this community, I should have posted it with a "#help" tag to indicate more clearly that I was soliciting feedback.&lt;/p&gt;

&lt;p&gt;To sum up, I'm getting some resistance in moving to CI/CD, and I was looking for feedback any of you who have made the transition. If you've faced resistance from your teammates, how did you help them get to a place where they felt more comfortable? For some more context, here's the original post: &lt;a href="https://dev.to/rbseaver/continuous-integration-and-code-reviews-13bc"&gt;https://dev.to/rbseaver/continuous-integration-and-code-reviews-13bc&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Thanks in advance for any advice!&lt;/p&gt;

</description>
      <category>help</category>
    </item>
    <item>
      <title>Continuous Integration and Code Reviews</title>
      <dc:creator>Rob Seaver</dc:creator>
      <pubDate>Fri, 06 Sep 2019 22:19:15 +0000</pubDate>
      <link>https://dev.to/rbseaver/continuous-integration-and-code-reviews-13bc</link>
      <guid>https://dev.to/rbseaver/continuous-integration-and-code-reviews-13bc</guid>
      <description>&lt;p&gt;I'm working on moving my team to a continuous integration process. Right now, we do work in a feature branch and once the feature is complete, we submit it a pull request for code review/merging. However, I'm not a fan of introducing large features all at once, which requires someone to spend part of their day reviewing dozens (and sometimes 100+) changes in a single code review session. Small commits are ideal and make it much easier to identify problematic code, and it obviously lends itself to more frequent releases. I suspect I'm preaching to the choir here, so I'll avoid extolling the virtues of CI/CD.&lt;/p&gt;

&lt;p&gt;Most of my team is on board, but one of our team members is a bit resistant to this change. I am completely empathetic to his position, however. His concern is that when we introduce many small commits over time, it becomes difficult to review the feature in its entirety to make sure the code is consistent and works with all of the previous pieces of code that were introduced. My position is that automated testing directly addresses his concern. It will become apparent pretty quickly if new code is incompatible with previous code, based on the automated test results. Bite-sized commits are much easier for a reviewer to digest, and allow the reviewer to focus on style, readability, etc..., instead of whether the code works properly.&lt;/p&gt;

&lt;p&gt;Has anyone else transitioned to continuous integration and faced resistance along the way? How have you addressed it with your team? Thanks in advance for any input!&lt;/p&gt;

&lt;p&gt;Please forgive any grammatical errors or lack of clarity. It is Friday afternoon and I'm struggling to put my thoughts together after a long week (and it's hard to want to think about work after you've gotten home) :)&lt;/p&gt;

</description>
      <category>discuss</category>
      <category>devops</category>
      <category>codequality</category>
      <category>testing</category>
    </item>
  </channel>
</rss>
