<?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>Forem: Wiktor Mociun</title>
    <description>The latest articles on Forem by Wiktor Mociun (@voter101).</description>
    <link>https://forem.com/voter101</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%2F78579%2F6897c7f4-e997-4423-bf30-ed820bf8d14a.jpeg</url>
      <title>Forem: Wiktor Mociun</title>
      <link>https://forem.com/voter101</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://forem.com/feed/voter101"/>
    <language>en</language>
    <item>
      <title>Faster Heroku deploys with Rails and webpacker</title>
      <dc:creator>Wiktor Mociun</dc:creator>
      <pubDate>Tue, 27 Aug 2019 10:53:16 +0000</pubDate>
      <link>https://forem.com/voter101/faster-heroku-deploys-with-rails-and-webpacker-2ej0</link>
      <guid>https://forem.com/voter101/faster-heroku-deploys-with-rails-and-webpacker-2ej0</guid>
      <description>&lt;p&gt;Originally posted on: &lt;a href="https://mociun.xyz/faster-heroku-deploys-with-rails-and-webpacker/" rel="noopener noreferrer"&gt;https://mociun.xyz/faster-heroku-deploys-with-rails-and-webpacker/&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Some time ago in &lt;a href="https://pilot.co" rel="noopener noreferrer"&gt;Pilot&lt;/a&gt;, we switched to use &lt;a href="https://github.com/rails/webpacker" rel="noopener noreferrer"&gt;webpacker&lt;/a&gt; as a tool for compiling our JavaScript code. It is a simple way to integrate webpack into your Rails project.&lt;/p&gt;

&lt;p&gt;Lately, we noticed that our Heroku deploys got frustratingly long. Over 10 minutes to build and release our main application wasn't acceptable. Add CI runtime and Heroku's &lt;a href="https://devcenter.heroku.com/articles/preboot#deploying-with-preboot" rel="noopener noreferrer"&gt;preboot&lt;/a&gt; to the mix and now we could easily end up with around 25-30 minutes of full deploy time. This was getting very annoying when trying to ship a hotfix.&lt;/p&gt;

&lt;p&gt;What if we could make it shorter?&lt;/p&gt;

&lt;h2&gt;
  
  
  What's going on?
&lt;/h2&gt;

&lt;p&gt;The biggest chunk of time in the build process has been asset compilation. With each build, Heroku was installing all npm dependencies (using yarn) and compiling webpacker assets from scratch. It took very long with each build, even if we didn't touch any code (deploying the same code twice).&lt;/p&gt;

&lt;p&gt;Something didn't smell right as on local dev environment if there were no changes, the process ran in less than a second.&lt;/p&gt;

&lt;p&gt;As time passed, we also noticed that our slug size was growing, which causes deploys to be longer. There were lots of uncleaned leftovers after each webpacker build. Simple &lt;a href="https://github.com/heroku/heroku-repo" rel="noopener noreferrer"&gt;repo purging&lt;/a&gt; was enough to get rid of this problem, but it required manual command execution.&lt;br&gt;
&lt;em&gt;‌&lt;/em&gt;&lt;br&gt;
It was clear that there are a couple of problems:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Yarn cache isn't re-used.&lt;/li&gt;
&lt;li&gt;Full webpacker build runs even if JavaScript code was not touched.&lt;/li&gt;
&lt;li&gt;Old build products were not cleaned.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2&gt;
  
  
  Getting to a solution
&lt;/h2&gt;

&lt;p&gt;Luckily some people already &lt;a href="https://github.com/heroku/heroku-buildpack-ruby/pull/892" rel="noopener noreferrer"&gt;worked on a solution&lt;/a&gt;. With that webpacker will reuse the previous build if JavaScript files were not touched. Otherwise, webpacker will do a full rebuild. On top of that, these changes include a Yarn cache, which remedies problems with dependencies installation (however this could be achieved installing official node.js buildpack from Heroku).&lt;/p&gt;

&lt;p&gt;Another problem is that webpacker &lt;a href="https://github.com/rails/webpacker/issues/1410" rel="noopener noreferrer"&gt;does not ship with a cleaning task&lt;/a&gt; (similar to &lt;code&gt;assets:clean&lt;/code&gt;). Without it, the slug size of our application will keep growing in time. Luckily for us, there is a webpack plugin called &lt;a href="https://github.com/johnagan/clean-webpack-plugin" rel="noopener noreferrer"&gt;clean-webpack-plugin&lt;/a&gt; that does exactly this.&lt;/p&gt;

&lt;p&gt;Combining that plugin and making a little tweak in the &lt;a href="https://github.com/heroku/heroku-buildpack-ruby/pull/892" rel="noopener noreferrer"&gt;solution&lt;/a&gt; by &lt;a href="https://github.com/kpheasey" rel="noopener noreferrer"&gt;@kpheasey&lt;/a&gt; we can achieve the effect we want. We included that tweak on our GitHub fork of &lt;a href="https://github.com/pilotcreative/heroku-buildpack-ruby/tree/feat/yarn-cache" rel="noopener noreferrer"&gt;&lt;code&gt;heroku-buildpack-ruby&lt;/code&gt;&lt;/a&gt;.  &lt;/p&gt;
&lt;h2&gt;
  
  
  Putting the solution together
&lt;/h2&gt;

&lt;blockquote&gt;
&lt;h4&gt;
  
  
  Technical Note:
&lt;/h4&gt;

&lt;p&gt;This solution works on Rails versions &amp;gt;= 5.1, &amp;lt; 6.0. Though, it should be easy to modify it to work with other versions. :)&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;Firstly, you need to have &lt;code&gt;clean-webpack-plugin&lt;/code&gt; in place:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;yarn add clean-webpack-plugin
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;Now add plugin's config code to &lt;code&gt;config/webpack/environment.js&lt;/code&gt;:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight javascript"&gt;&lt;code&gt;&lt;span class="c1"&gt;// ...&lt;/span&gt;
&lt;span class="kd"&gt;const&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt; &lt;span class="nx"&gt;CleanWebpackPlugin&lt;/span&gt; &lt;span class="p"&gt;}&lt;/span&gt; &lt;span class="o"&gt;=&lt;/span&gt; &lt;span class="nf"&gt;require&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="dl"&gt;"&lt;/span&gt;&lt;span class="s2"&gt;clean-webpack-plugin&lt;/span&gt;&lt;span class="dl"&gt;"&lt;/span&gt;&lt;span class="p"&gt;);&lt;/span&gt;

&lt;span class="nx"&gt;environment&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nx"&gt;plugins&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;prepend&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="dl"&gt;"&lt;/span&gt;&lt;span class="s2"&gt;CleanWebpackPlugin&lt;/span&gt;&lt;span class="dl"&gt;"&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="k"&gt;new&lt;/span&gt; &lt;span class="nc"&gt;CleanWebpackPlugin&lt;/span&gt;&lt;span class="p"&gt;());&lt;/span&gt;

&lt;span class="c1"&gt;// ...&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;And the last step – &lt;em&gt;replace&lt;/em&gt; the official Ruby buildpack with the custom one in your app's &lt;em&gt;Settings&lt;/em&gt; on Heroku.&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;https://github.com/pilotcreative/heroku-buildpack-ruby.git#feat/yarn-cache
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;&lt;a href="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fthepracticaldev.s3.amazonaws.com%2Fi%2Fxpcrvbmdkec2jz0od5d8.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fthepracticaldev.s3.amazonaws.com%2Fi%2Fxpcrvbmdkec2jz0od5d8.png" alt="Heroku buildpacks of one of our apps"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Now run a full build to build your cache and you're done! For us builds take from 2.5 to 5 minutes depending on what changes are being deployed. &lt;/p&gt;

&lt;h2&gt;
  
  
  Sources
&lt;/h2&gt;

&lt;ul&gt;
&lt;li&gt;&lt;a href="https://github.com/rails/webpacker/issues/1410" rel="noopener noreferrer"&gt;https://github.com/rails/webpacker/issues/1410&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://github.com/heroku/heroku-buildpack-ruby/pull/892" rel="noopener noreferrer"&gt;https://github.com/heroku/heroku-buildpack-ruby/pull/892&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://github.com/johnagan/clean-webpack-plugin" rel="noopener noreferrer"&gt;https://github.com/johnagan/clean-webpack-plugin&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://github.com/rails/webpacker/pull/1744" rel="noopener noreferrer"&gt;https://github.com/rails/webpacker/pull/1744&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://thoughtbot.com/blog/how-to-reduce-a-large-heroku-compiled-slug-size" rel="noopener noreferrer"&gt;https://thoughtbot.com/blog/how-to-reduce-a-large-heroku-compiled-slug-size&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;

</description>
      <category>rails</category>
      <category>heroku</category>
      <category>webpack</category>
      <category>webpacker</category>
    </item>
    <item>
      <title>Quick terminal tip</title>
      <dc:creator>Wiktor Mociun</dc:creator>
      <pubDate>Thu, 14 Jun 2018 21:26:20 +0000</pubDate>
      <link>https://forem.com/voter101/quick-terminal-tip-1can</link>
      <guid>https://forem.com/voter101/quick-terminal-tip-1can</guid>
      <description>&lt;p&gt;Originally posted on: &lt;a href="https://mociun.xyz/quick-terminal-tip/"&gt;https://mociun.xyz/quick-terminal-tip/&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;There is one small thing that made my life as a software developer a little better. And not many people seem to know about it.&lt;/p&gt;

&lt;p&gt;The trick is hotkey terminal window. It is basically an additional terminal window that is always visible, and you can show/hide it using a keyboard shortcut.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://res.cloudinary.com/practicaldev/image/fetch/s--TEDay1yn--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://cdn-images-1.medium.com/max/1600/1%2A6Pq051EVu6ORgiZ323XYeg.gif" class="article-body-image-wrapper"&gt;&lt;img src="https://res.cloudinary.com/practicaldev/image/fetch/s--TEDay1yn--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://cdn-images-1.medium.com/max/1600/1%2A6Pq051EVu6ORgiZ323XYeg.gif" alt="Additional window!"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;This additional window seemed to be really handy as a code scratchpad or dedicated man window. It is so convenient that I sometimes use it as themain terminal.&lt;/p&gt;

&lt;p&gt;I believe this feature should be available on most platforms. I personally use iTerm2 (Mac only, sorry) and it has this functionality built-in. In my case, the new window show/hide up after I press CTRL two times.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://res.cloudinary.com/practicaldev/image/fetch/s--pyF1HQ65--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://cdn-images-1.medium.com/max/1600/1%2Ad8_oE_voBZW5cnwPwFlnvA.png" class="article-body-image-wrapper"&gt;&lt;img src="https://res.cloudinary.com/practicaldev/image/fetch/s--pyF1HQ65--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://cdn-images-1.medium.com/max/1600/1%2Ad8_oE_voBZW5cnwPwFlnvA.png" alt="Setup hotkey window in iTerm2&amp;lt;br&amp;gt;
"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Originally posted at: &lt;a href="https://medium.com/the-runway/quick-tip-for-mac-keep-handy-additional-terminal-window-fe7bb7ab49eb"&gt;Medium&lt;/a&gt;&lt;/p&gt;

</description>
      <category>terminal</category>
      <category>osx</category>
      <category>productivity</category>
      <category>programming</category>
    </item>
  </channel>
</rss>
