<?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: Alexander Martinez</title>
    <description>The latest articles on DEV Community by Alexander Martinez (@cosmouser).</description>
    <link>https://dev.to/cosmouser</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%2F354611%2F958bf854-175c-415b-b260-90bf7051077d.png</url>
      <title>DEV Community: Alexander Martinez</title>
      <link>https://dev.to/cosmouser</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/cosmouser"/>
    <language>en</language>
    <item>
      <title>Shortcut to Theming Websites</title>
      <dc:creator>Alexander Martinez</dc:creator>
      <pubDate>Mon, 27 Apr 2020 16:37:59 +0000</pubDate>
      <link>https://dev.to/cosmouser/shortcut-to-theming-websites-f57</link>
      <guid>https://dev.to/cosmouser/shortcut-to-theming-websites-f57</guid>
      <description>&lt;p&gt;A lot of programmers will create a prototype of something with minimal styling to prove a concept and say, "I know it's ugly, I am not a designer." This has always irked me from several angles. First, the line sounds vaguely like a humble brag that they're a programmer, not a designer, and that an eye for design is lower on the totem pole than talent in coding. Second, being self deprecating in a presentation, no matter how informal, is generally a bad idea. Finally, regardless of how much time developers work on their projects, it's often much longer than they would like to admit. Why not look at something more pleasing to the eye while building it?&lt;/p&gt;

&lt;p&gt;One confession I must make is that every once in a while, I will procrastinate on a project by twiddling with the color theme in my terminal. Since I code in Vim most of the time, the terminal is where all of my interaction with the machine happens. The way that I often justify going about configuring my color theme stems from how my eyes are feeling. After a while my eyes may hurt from staring at the screen and the idea that changing the terminal's colors may make it easier to work slips into my head. There's a saying that goes, "the best lies are the ones with a little bit of truth in them." and that's exactly why this can convince me to deviate from the task at hand. In truth, taking a short break and coming back to the project with fresh eyes is the better course of action. Changing the theme still feels like work, though, and also led me to share this with you.&lt;/p&gt;

&lt;p&gt;A lot of what I just wrote should set off design alarm bells in your head. Interacting with a machine and keeping track of how you feel when you're working with it. Designing a workspace to fit your subjective tastes. These are things that designers do. Voila, you're a designer. Some terminal emulators with GUIs have dropdowns containing dozens or hundreds of themes. Pick one and use the colors from it for your site. Or, go to a terminal theme designer website and randomly generate themes until you find one that fits your fancy. The algorithms behind these generators are often tuned to generate sets of colors that are designed to be legible and pleasing when used together.&lt;/p&gt;

&lt;p&gt;After you start flipping through colors to use for your site, you won't be procrastinating any longer. Now you're theming your project. Now you're working! It will be easier for you to be proud of what you're sharing with your audience and easier for them to look at.&lt;/p&gt;

</description>
      <category>webdev</category>
      <category>ux</category>
      <category>design</category>
    </item>
    <item>
      <title>Automated Deployments from Scratch</title>
      <dc:creator>Alexander Martinez</dc:creator>
      <pubDate>Tue, 24 Mar 2020 01:35:00 +0000</pubDate>
      <link>https://dev.to/cosmouser/automated-deployments-from-scratch-5b3m</link>
      <guid>https://dev.to/cosmouser/automated-deployments-from-scratch-5b3m</guid>
      <description>&lt;p&gt;I'm going to share a simple method for automating your deployments from scratch.&lt;/p&gt;

&lt;p&gt;While working on a project that uses Go and React, I realized that there were too many steps in the deployment process to do it manually. I needed to generate assets for transfer using three different programs, then I needed to send it over to my production host, and then I needed to move those assets into place in production. I had read about using git hooks to do this kind of thing before, so I looked into them. It turns out that git hooks are easy to use. You just put a script into the .git/hooks/ folder and name it after the event that you want it to be executed during.&lt;/p&gt;

&lt;p&gt;I used the pre-commit hook, and wrote a bash script for compiling all of the assets, compressing them, and scp'ing them to my production server.&lt;/p&gt;

&lt;p&gt;Now doing git commit -a causes a compile, packaging, and transfer of the compressed assets to the production server. What is left though, is to have the production server automatically install the new assets. As a solution, I wrote a watcher script that polls for changes in a file.&lt;/p&gt;

&lt;p&gt;The watcher script runs on the production host and looks for changes in the file that the pre-commit hook pushes to it. When the file changes, it unpacks the archive, stops the app, installs the assets, removes leftover artifacts and starts the app.&lt;/p&gt;

&lt;p&gt;That's it. Automated deployments with git and a couple of bash scripts. One script in your development environment that's kicked off by git and another on your production host that's triggered on a file change.&lt;/p&gt;

</description>
      <category>devops</category>
      <category>git</category>
    </item>
  </channel>
</rss>
