git clean

The documentation for git clean is clear, but still it’s long. So here comes the summary

git clean -n # Dry run, show list of untracked files to be deleted
git clean -n -x # Dry run, show list of untracked + ignored files to be deleted

git clean -f # Remove untracked files

git clean -x -f # Remove untracked + ignored files

The order of middlewares matter

Despite having working with Ruby for more than 6 months, I have never really understood the usage of middlewares inside a Rack application.

We are working on a problem to set the X-Request-Id header for the incoming request, and we would like to have that header in the response as well.

So for setting the header, we use a middleware layer, named RequestId. Initially I thought we would need another middleware to set a header for a response as well, but no, we do not need it.

A request is coming to Rack app with its set of headers. Then whenever we modify the headers for the Rack app

This is the sample response from Rack app. It’s an array with 3 elements:

  • an Integer: HTTP status code
  • a Hash: Some headers
  • an Array: The response body
map <span class="hljs-string">'/posts'</span> <span class="hljs-keyword">do</span>
run Proc.<span class="hljs-keyword">new</span> { |env| [<span class="hljs-string">'200'</span>, {<span class="hljs-string">'Content-Type'</span> => <span class="hljs-string">'text/html'</span>}, [<span class="hljs-string">'first_post'</span>, <span class="hljs-string">'second_post'</span>, <span class="hljs-string">'third_post'</span>]] }

Each Rack app is required to return the array with 3 elements. Hence once we have a middleware to modify the response of Rack app, then it’s there.

To read more: Proper Rack Middleware Ordering | Verbose Logging Рthis is really useful website that help me to understand how the chain of middlewares are interacting with each other.