1 2 3 4 5 6 7 8
For bonus points,
response.code == 206 tells you that you got your
“Partial Content”. A code of
200 would tell you that the Range was
ignored and you got the whole file.
There a couple of other features of the Range header that are worth mentioning…
What if I told you that you could create a API backend that didn’t require any code? Crazy right? Wrong!
When I run into a problem I can’t and the Google doesn’t have it, I document it for the next person.
gpg --check-trustdb and
gpg --update-trustdb commands report
the problem, but do not repair it.
A quickie today, renaming a bunch of files in the shell. Unix gives you million ways to do it, here are a few that will help you understand your tools better.
The word has come down, Uber is the new Awesome and our files must reflect this (management is behind the curve, but they pay the bills).
To securely access your servers you use SSH keys. Passwords can be
guessed, just look in your logs to see all the people trying. But, you
know that. You’ve got one key to rule them all added to
.ssh/authorized_keys on the servers you manage. You may have even
disabled passwords altogether by setting:
1 2 3
But, how many keys to you have?
So, you’re on a rescue project with some legacy code (and by “legacy” I almost always mean PHP). The old developer probably just FTP’ed changes up to the server. You could do the same, but frankly that fills me with dread. On a good day I don’t like deploys. What if something goes wrong?!?!?! To help me to relax, I use good tools that let me trust my deploy and allow me to rollback if something doesn’t work.
In a Rails project you’d get that security from Capistrano. Turns out that’s the right tool for you legacy project as well. Capistrano 2 had a few, easily addressed, Rails-centric tasks. However, Capistrano 3 is framework agnostic by default. (Am I implying PHP is a framework? No, I am not.)
While the fame and free cars are nice, the reason I blog is to learn, or, as in this case, to help me remember things.
I work across a number of distinct Rails projects that share a common ancestry. Often a bug fix or a new feature in one needs to be ported to (some of) the others.
Because projects all live in their own repos, the changes can not be merged using Git. No, this is a job for patches. And when it comes to patching with Git, there are two posts about the process I can not live without.