<?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: PaperDrago</title>
    <description>The latest articles on DEV Community by PaperDrago (@paperdrago).</description>
    <link>https://dev.to/paperdrago</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%2F2043329%2F62ecdc7f-a6f5-42fa-9cbf-c81a170ddc01.png</url>
      <title>DEV Community: PaperDrago</title>
      <link>https://dev.to/paperdrago</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/paperdrago"/>
    <language>en</language>
    <item>
      <title>Project 3</title>
      <dc:creator>PaperDrago</dc:creator>
      <pubDate>Wed, 06 Nov 2024 01:43:45 +0000</pubDate>
      <link>https://dev.to/paperdrago/project-3-39kf</link>
      <guid>https://dev.to/paperdrago/project-3-39kf</guid>
      <description>&lt;p&gt;This project I found to be the most confusing of all. Its a project where we have different divisions within the class where 1/2 is atari the other half is nintendo. Within each division we have four different groups responsible for making a tetris clone working and to add other extra features. That in it of itself isn't bad, but the problem I had at the start was that the first division meeting was during a time when I was working. So, a small group decided that tasks are divided up by roles and not groups. So, people who couldn't tend the meeting because of work or other obligations weren't able to express their opinions on the matter. By the time the second meeting was done it was merely a recap. To be fair to them, it makes sense that the decisions are made fast since we only have two weeks for the project, and roughly a week per task (documentation and coding). So far it was a project that felt to be extremely uneven in work load, I feel a certain amount of guild that I did not do a lot of work so I tried to help outside of my task. That being I made the bricks for the tetris team to use, and then I did my normal task of finding bugs while playing the game. I don't particularly know how I feel about this project.&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Project 2</title>
      <dc:creator>PaperDrago</dc:creator>
      <pubDate>Wed, 23 Oct 2024 15:05:33 +0000</pubDate>
      <link>https://dev.to/paperdrago/project-2-hc0</link>
      <guid>https://dev.to/paperdrago/project-2-hc0</guid>
      <description>&lt;p&gt;I found that the easy part of the project was the first half of it. That being the design document where I and two other people were in charge of making the document. I did a lot of the cursory, specific requirements and the initial formatting while also throwing some ideas of what we would write about. This part was finished fairly quickly and without issues.&lt;br&gt;
    The biggest issue I found is that we changed the manner in which we were going to complete the implementation phase last minute. Initially I suggested we split it half of the workers do the first part of the project and half the workers do the next. Instead, the project was split where each person did a method or two which has now led to annoying problems. That being there isn’t enough cohesion in the code, and some people didn’t follow the design documentation correctly.&lt;br&gt;
    I think the biggest issue with the implementation phase was a lack of direct leadership and initiative, that being we didn’t have enough people finish their work in a timely manner which backlogged other people’s work. This class has really been an exercise in learning how to manage the time of a whole group which is by far more complex than I really expected.&lt;br&gt;
I think we could have solved these issues far more elegantly if we set our deadlines earlier in the week instead of Monday. Perhaps Sunday night would be better so we can make changes Monday, communicate Tuesday for last minute fixes, and have a perfectly working product Wednesday. But since the deadline we chose was Monday, our crunch is more severe.&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Project 1: Unit Testing</title>
      <dc:creator>PaperDrago</dc:creator>
      <pubDate>Tue, 08 Oct 2024 22:41:18 +0000</pubDate>
      <link>https://dev.to/paperdrago/project-1-unit-testing-403m</link>
      <guid>https://dev.to/paperdrago/project-1-unit-testing-403m</guid>
      <description>&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;This assignment started out easily enough. I was confident when I first started since I had already a decent foundation on Git and some of the git commands that were most used. The actual git/github portion of the assignment was ultimately really easy, and I got to use the revert command that I rarely touch. 
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;

&lt;p&gt;Ultimately this felt like a much more difficult assignment than I initially predicted. It felt like a nice refresher on Java programming but I honestly spent too much of my summer with Python so I struggled a good amount. That and I hadn’t taken a formal programming course in roughly two years didn’t help me. It was definitely an experience but I am comforted in knowing that the purpose of this assignment wasn’t the code itself but the utilization of git and github.&lt;br&gt;
I think it was helpful that I ended up using vs code for this, and running distro through it for ubuntu. It's easy to use and it has a lot of functionality that makes looking at branches and commits really easy. I bet there are more efficient ways to do this but this works for now so I'll explore it a little more as I progress through this class. &lt;br&gt;
What more concerns me is just the act of pulling requests and working as a team, because it's one thing to know how to use github for your own projects and another thing to use it with a team. I think there could be a lot of friction and a lot of problems if the team isn’t careful with their resets and such.&lt;/p&gt;

&lt;p&gt;After finishing the project with my team, I think I was a little too nervous at the start for what we actually ended up doing. Our team dynamic isn’t exactly talkative but problems and questions get responded to very quickly and efficiently. I’m especially pleased that for a group of 8 we had very little issues with finishing the work in a fairly timely manner. We had some small hiccups with assignment organization and formatting but those were minor and fairly easily solved.&lt;br&gt;
At most, the worst part was that beginning part with setting up team roles, meetings, and ensuring people were clear with their roles. Otherwise, it was very easy with the actual coding aspects of the project. Some simple unit tests and some minor documentation were really the only thing that was required so I was pretty happy.&lt;br&gt;
Personally I tried to finish this project fairly early on so I did most of the tests in a day… but I forgot to do the pull request and only saved it on my machine. So, when I remembered that I had to upload it to github I quickly did a merge request and it was validated relatively quickly, I think 1 day or so. &lt;br&gt;
For the final finishing touches I just gave an alert on our teams and then fixed my mistakes and did another pull request. Overall, I think my team did well, even though I didn’t really talk to them other than the one time on Tuesday as a part of our team meeting. Though, I do appreciate that one of the other group members set up another meeting time on Thursday for support if need be. &lt;/p&gt;

</description>
    </item>
    <item>
      <title>Assignment 2</title>
      <dc:creator>PaperDrago</dc:creator>
      <pubDate>Fri, 20 Sep 2024 03:31:22 +0000</pubDate>
      <link>https://dev.to/paperdrago/assignment-2-286m</link>
      <guid>https://dev.to/paperdrago/assignment-2-286m</guid>
      <description>&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;This assignment started out easily enough. I was confident when I first started since I had already a decent foundation on Git and some of the git commands that were most used. The actual git/github portion of the assignment was ultimately really easy, and I got to use the revert command that I rarely touch. 
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;

&lt;p&gt;Ultimately this felt like a much more difficult assignment than I initially predicted. It felt like a nice refresher on Java programming but I honestly spent too much of my summer with Python so I struggled a good amount. That and I hadn’t taken a formal programming course in roughly two years didn’t help me. It was definitely an experience but I am comforted in knowing that the purpose of this assignment wasn’t the code itself but the utilization of git and github.&lt;br&gt;
I think it was helpful that I ended up using vs code for this, and running distro through it for ubuntu. It's easy to use and it has a lot of functionality that makes looking at branches and commits really easy. I bet there are more efficient ways to do this but this works for now so I'll explore it a little more as I progress through this class. &lt;br&gt;
What more concerns me is just the act of pulling requests and working as a team, because it's one thing to know how to use github for your own projects and another thing to use it with a team. I think there could be a lot of friction and a lot of problems if the team isn’t careful with their resets and such.&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Blog 1 - Assignment 1</title>
      <dc:creator>PaperDrago</dc:creator>
      <pubDate>Mon, 09 Sep 2024 02:58:45 +0000</pubDate>
      <link>https://dev.to/paperdrago/blog-1-assignment-1-c2m</link>
      <guid>https://dev.to/paperdrago/blog-1-assignment-1-c2m</guid>
      <description>&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;For this first assignment I didn’t feel like it was logically very difficult. I think my struggle came more from the rustyness of not using Java in a while. So, it was more of a slow start remembering how to correctly do a loop and use the scanner than difficulty with the fibonacci sequence. I think the actual coding part was simple and refreshing more than anything. Kind of like polishing an old watch, it was still working and fine but seeing it recover some of its old shine is rewarding.
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;

&lt;p&gt;I’m not totally sure what to expect from this course, though I will say I am kind of nervous about all the group projects. Throughout DePauls classes I haven’t ever needed to work with others for programming but I expect this will be a good first taste in real project development.&lt;br&gt;
It's also a good opportunity to review a git course I had watched a while ago and give it a quick runover to make future projects a little more simple since I know it through visual studio. Though, github is a different beast since I didn’t have to use its UI to use git. Deleting stuff and making sure the file was in the right place was a little frustrating.&lt;br&gt;&lt;br&gt;
Overall, I’m excited that the focus isn’t spread between in person, flex, and remote students. It gives an interesting work environment that is, probably, more common in the software industry.  &lt;/p&gt;

</description>
    </item>
  </channel>
</rss>
