<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Developer Tools on BradCypert.com</title>
    <link>https://www.bradcypert.com/tags/developer-tools/</link>
    <description>Recent content in Developer Tools on BradCypert.com</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 27 Dec 2022 22:25:45 -0500</lastBuildDate>
    <atom:link href="https://www.bradcypert.com/tags/developer-tools/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Simple NPM Wrapper using NVM</title>
      <link>https://www.bradcypert.com/simple-npm-wrapper-using-nvm/</link>
      <pubDate>Thu, 07 Jun 2018 00:00:00 +0000</pubDate>
      <guid>https://www.bradcypert.com/simple-npm-wrapper-using-nvm/</guid>
      <description>&lt;p&gt;The NPM team has always done a pretty good job of not requiring a specific version of NPM to execute most of it’s commands properly. However, with the recent addition of the package-lock file (and the recent tinkering of the package-lock file across some of the more recent releases of NPM), it’s starting to become a bit of a pain to manage. I work with developers using a gamut of NPM versions from 5.1.1 to 6.0.1. These may sound like minor version changes but since 5.6.0, most of the changes have included changes to the package-lock file. More importantly, this generates a lot of a noise in PRs (we check to ensure that package-lock changes are actually warranted as we’ve had child dependencies break on us in the past) and that causes confusion and takes time to sift through.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Modifying incoming requests via Charles Proxy</title>
      <link>https://www.bradcypert.com/modifying-incoming-requests-via-charles-proxy/</link>
      <pubDate>Thu, 08 Mar 2018 00:00:00 +0000</pubDate>
      <guid>https://www.bradcypert.com/modifying-incoming-requests-via-charles-proxy/</guid>
      <description>&lt;p&gt;Charles Proxy is an outstanding development tool that I’ve recently started to fall in love with. I think the most practical use of this tool is probably using the rewrite tool to rewrite outgoing or incoming requests, however, I’m going to talk to you about setting up request breakpoints. Breakpoints allow you to halt an incoming or outgoing requests, possibly modify it, and send it whenever you’re content with it. It’s a fantastic tool for simulating edge-cases like making an http request to a server that wraps and returns the response of a request that it makes.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
