<?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: Nico</title>
    <description>The latest articles on DEV Community by Nico (@nxcco).</description>
    <link>https://dev.to/nxcco</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%2F402727%2F2a2989ed-6005-436d-8df0-d9313f7c5a94.JPG</url>
      <title>DEV Community: Nico</title>
      <link>https://dev.to/nxcco</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/nxcco"/>
    <language>en</language>
    <item>
      <title>Introduction</title>
      <dc:creator>Nico</dc:creator>
      <pubDate>Sat, 29 May 2021 19:43:50 +0000</pubDate>
      <link>https://dev.to/nxcco/introduction-mg3</link>
      <guid>https://dev.to/nxcco/introduction-mg3</guid>
      <description>&lt;h4&gt;
  
  
  Preface
&lt;/h4&gt;

&lt;p&gt;Gradle's documentation is more than only hard to read - oftentimes it feels like an information deadlock, where one document refers to another, which in turn refers back to the document you came from. In addition, parts of the descriptions, examples and practices are completely or partially outdated. All in all, despite the richness of the docs, it's uncleanly written and apparently does not receive any maintenance and care. Even Thehe company provides free trainings on the powerful build tool, however, a proper guide would make Gradle far more accessible to developers. That's the reason this guide exists.&lt;/p&gt;

&lt;h4&gt;
  
  
  The goal of this guide
&lt;/h4&gt;

&lt;p&gt;The goal of this guide is not to introduce you to every feature of Gradle. Gradle is extensive and full of functionality. But I think, the purpose of a guide isn't explaining everything in detail anyway. It rather aims to cover the basic and some advanced concepts together with the fundamental mechanisms, giving you the knowledge to go on with your own research about the Gradle build tool. With that said, let's start!&lt;/p&gt;




&lt;h1&gt;
  
  
  What is Gradle and how does it work?
&lt;/h1&gt;

&lt;p&gt;Gradle is an open-source &lt;a href="https://en.wikipedia.org/wiki/Build_automation"&gt;build automation&lt;/a&gt; tool that is designed to be flexible enough to build almost any type of software. It's extremely extensible and customizable. In fact, the actual building tool is nothing more than a framework which needs to be filled with custom logic. &lt;/p&gt;

&lt;p&gt;Gradle is based on Java, hence running inside the JVM. To instruct Gradle to build a project, we have to provide it information about &lt;strong&gt;what&lt;/strong&gt; and &lt;strong&gt;how&lt;/strong&gt; that should be accomplished. So the logic (e.g. compiling source files) has first to be added to Gradle - it does not do that out of the box! Fortunately, those things are already implemented by other developers and packaged for use, so there is (in most cases) no need for us to reinvent the wheel. Instead, we can just take that package and say that this &lt;strong&gt;task&lt;/strong&gt; should be executed for us. Those &lt;em&gt;tasks&lt;/em&gt; and "packaged logic" (spoiler: those are called plugins) are some of the basic concepts you learn about soon.&lt;/p&gt;

&lt;h1&gt;
  
  
  Installing Gradle
&lt;/h1&gt;

&lt;p&gt;To be able to run Gradle and experiment alongside reading this guide (I highly recommend you to experiment), first of all you need to install Gradle. As the whole process of how to do that is well-documented by the Gradle documentation itself, I just refer to it &lt;a href="https://docs.gradle.org/current/userguide/installation.html"&gt;here&lt;/a&gt;.&lt;br&gt;
Now as you have Gradle installed, you can run a lot of commands. An overview you can find &lt;a href="https://docs.gradle.org/current/userguide/command_line_interface.html"&gt;here&lt;/a&gt;.&lt;/p&gt;




&lt;p&gt;If you have any questions or constructive criticism on the articles, post them in the discussion section below!&lt;/p&gt;

</description>
      <category>gradle</category>
      <category>guide</category>
      <category>tutorial</category>
    </item>
    <item>
      <title>My learnings</title>
      <dc:creator>Nico</dc:creator>
      <pubDate>Sun, 03 Jan 2021 14:21:33 +0000</pubDate>
      <link>https://dev.to/nxcco/my-learnings-3gdh</link>
      <guid>https://dev.to/nxcco/my-learnings-3gdh</guid>
      <description>&lt;ol&gt;
&lt;li&gt;Don't shy away from lots of work to accomplish a task. If you do it anyway, the workload will come back even heavier.&lt;/li&gt;
&lt;li&gt;Test critical code. That means when you don't know whether it's working properly, test it. But also don't test every little piece. That is just time-wasting.&lt;/li&gt;
&lt;li&gt;One step at a time. When you do a task at a particular section of your code, focus onto it. When you see bugs, typos etc somewhere else, note it, but don't waste your focus fixing that issue quickly. Keep your focus.&lt;/li&gt;
&lt;li&gt;Make a beautiful todo list of the ongoing tasks. Break them down and WRITE it down. Otherwise you will often lose your thread.&lt;/li&gt;
&lt;li&gt;Plan new features thoroughly. Use pseudocode and think about what you could have missed in your first thinking phase. Think through the concept multiple times. It will save you time in the long run, as you won't make so much critical mistakes.&lt;/li&gt;
&lt;li&gt;Celebrate working code pieces. Really. Do it. You have done great work, no matter how small or complex the code.&lt;/li&gt;
&lt;li&gt;Don't expect your code to run without bugs the first time. However if it does, you are doing something really correctly (jump to tip 6).&lt;/li&gt;
&lt;li&gt;When you encounter a problem, write it down. Really deal with it, so that you really understand what the problem is. Then start asking questions. What do you need to know to solve this problem. Find answers. The problem should start to crystallize into smaller parts. Ask again questions, until you know everything essential to solve the problem.&lt;/li&gt;
&lt;li&gt;Beware of the edge cases. Those little nasty beats...&lt;/li&gt;
&lt;/ol&gt;

</description>
      <category>productivity</category>
      <category>tips</category>
    </item>
    <item>
      <title>How do you version your software?</title>
      <dc:creator>Nico</dc:creator>
      <pubDate>Mon, 13 Jul 2020 08:14:42 +0000</pubDate>
      <link>https://dev.to/nxcco/how-do-you-version-your-own-software-dm2</link>
      <guid>https://dev.to/nxcco/how-do-you-version-your-own-software-dm2</guid>
      <description>&lt;p&gt;There are different ways of versioning the own software. Public software e.g. should use the Semantic Versioning, but how do you do it in your own, private projects?&lt;/p&gt;

</description>
      <category>discuss</category>
    </item>
  </channel>
</rss>
