<?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: Jason Mandel</title>
    <description>The latest articles on DEV Community by Jason Mandel (@jmandel1027).</description>
    <link>https://dev.to/jmandel1027</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%2F213649%2F091e468b-ff95-4eef-813a-cc05b9b15bee.jpeg</url>
      <title>DEV Community: Jason Mandel</title>
      <link>https://dev.to/jmandel1027</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/jmandel1027"/>
    <language>en</language>
    <item>
      <title>Towards an Orthographic Development Environment: Small Beginnings</title>
      <dc:creator>Jason Mandel</dc:creator>
      <pubDate>Fri, 02 Dec 2022 00:52:11 +0000</pubDate>
      <link>https://dev.to/jmandel1027/towards-an-orthographic-development-environment-small-beginnings-45g1</link>
      <guid>https://dev.to/jmandel1027/towards-an-orthographic-development-environment-small-beginnings-45g1</guid>
      <description>&lt;p&gt;When writing software, we have to contend with different environments, runtimes, dependencies et. all across potentially several developers, CI/CD processes and cloud deployments. With all this variance between where the source code is written and where it is run, it can be hard to manage all the sidecar scripts and random bits of tooling that accumulate over time. &lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F0x6ay5hj0oesyqk1nab0.jpg" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F0x6ay5hj0oesyqk1nab0.jpg" alt="Image description" width="800" height="680"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href="https://en.wikipedia.org/wiki/Orthographic_projection" rel="noopener noreferrer"&gt;An axonometric projection&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;We all know containers have revolutionized how we build, deploy and test our services, I think this is only the beginning. A lot of teams run into challenges where they suffer from bloated zombie deployment code that no one understands, or some error prone manual process for creating releases. What if developers had a universal configurable control plane that is the interface for every stage of development and deployment? What if it consistently behaved the same way on any machine from localhost to prod?&lt;/p&gt;

&lt;p&gt;An la carte set of components operating under a common deployment interface like a helm chart and &lt;a href="https://tilt.dev/" rel="noopener noreferrer"&gt;tilt&lt;/a&gt;. Errors could be surfaced far before a release rolls out. And what about how code is organized and structured? If there's a small team, it can be often difficult to keep track of what is going on across a critical mass of repos. How can we design our systems with strong contracts and loose couplings? Developers need to be able to iterate quickly, but autogenerated APIs like Hasura, Postgrest and Postgraphile are not the answer.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fm8gnqrhvagwxd2nrqwfg.jpeg" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fm8gnqrhvagwxd2nrqwfg.jpeg" alt="Image description" width="723" height="482"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I've been thinking quite a bit about this lately at Cash and will be kicking off a new blog series on this subject. Going to throw out an obligatory disclaimer, these are just my opinions and do not reflect the stance of Cash Engineering. &lt;/p&gt;

&lt;p&gt;Every team, and problem have their own considerations. These abstractions may or may not work for your use case or teams. This is not intended to be the ideal setup, but rather an examination of strategies for spinning out the flywheel that allows devs to get going quickly.&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;The map is not the territory&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;For small to medium sized teams, I've found that monorepos offer a high degree of visibility for development, additionally with some effort on CI/CD it can drastically simplify the build processes while accelerating the cadence and reliability of deployments.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://github.com/jmandel1027/perspex" rel="noopener noreferrer"&gt;perspex&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Above is a sort of living sandbox that we'll be exploring in this series. Consider it a starter for Sourdough, I'll be exploring various topics and ideas on a generative basis. So rather than a more standard tutorial, this will be a bit more long form. Also if theres any ideas or suggestions, please open a PR! Contributions are totally welcome.&lt;/p&gt;

&lt;p&gt;stay tuned.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://github.com/jmandel1027" rel="noopener noreferrer"&gt;github&lt;/a&gt;&lt;br&gt;
&lt;a href="https://www.jmandel.io/" rel="noopener noreferrer"&gt;personal site&lt;/a&gt;&lt;/p&gt;

</description>
      <category>react</category>
      <category>nextjs</category>
      <category>webdev</category>
    </item>
  </channel>
</rss>
