4 changed files with 121 additions and 11 deletions
Split View
Diff Options
-
+10 -8TODO.md
-
+44 -0pages/coop-talk.md
-
+66 -0posts/edit-last-commit.md
-
+1 -3posts/personal-tech-ethics-audit.md
+ 10
- 8
TODO.md
View File
| @ -1,10 +1,12 @@ | |||
| # TODO: | |||
| *note: rough order of priority* | |||
| * [X] syntax highlighting stylesheets | |||
| * [ ] move away from Solarized in favor of similar overall feel with better contrast | |||
| * [ ] robots.txt | |||
| * [.] Post about sandboxing using Django | |||
| * [.] Webmentions!? | |||
| * [X] Receive | |||
| * [ ] Display | |||
| * [ ] notes type with syndication to Mastodon!? https://www.npmjs.com/package/mastodon | |||
| * [X] syntax highlighting stylesheets #f63a89ed | |||
| * [ ] make it easier to preview new posts locally #c469fcb8 | |||
| * [ ] move away from Solarized in favor of similar overall feel with better contrast #c7a7201b | |||
| * [ ] select in code blocks doesn't highlight right and it's a bummer #d6e7ace0 | |||
| * [ ] robots.txt #d1d17e85 | |||
| * [.] Post about sandboxing using Django #ac9c6244 | |||
| * [.] Webmentions!? #3c37c9a4 | |||
| * [X] Receive #3e73ead8 | |||
| * [ ] Display #4b7a8810 | |||
| * [ ] notes type with syndication to Mastodon!? https://www.npmjs.com/package/mastodon #8ac0211f | |||
+ 44
- 0
pages/coop-talk.md
View File
| @ -0,0 +1,44 @@ | |||
| --- | |||
| title: Some Goals and Preferences for Co-Op Formation | |||
| description: To be taken as the mildly-organized brain-dump it is. | |||
| created: 2021-03-01 | |||
| tags: | |||
| - coop | |||
| - personal | |||
| - political | |||
| --- | |||
| Fair warning, there's a range of thoughts and impulses in here, from real practical concerns, to personal/professional boundaries, to pie-in-the-sky ideation with a strong political/emotional component. Not everything listed is a dealbreaker but I'd rather err on the side of thorough and transparent. | |||
| First of all, before we get too far with this, I would have some real hesitation about founding a co-op of only white men. I've seen a number of groups say they wanted to eventually reach out more and build a more diverse base, but there's a shared wisdom in organizing that your group will take a long time to outgrow the demographic profile of the founding members, if it *ever* does, so the responsible/equitable approach is to build something that is multi-racial, multi-ethnic, multi-cultural, gender/sexuality diverse from day one, ***and*** that acknowledges that diversity is a starting point for equity & inclusion, not an endpoint. | |||
| My goals for the group are to build an organization that outlives any individual member's participation, gives stakeholders more safety and stability to make a positive impact in their local social and ecological systems, invests in the long future technologically, socially, and spiritually, and uplifts groups underrepresented and/or underserved by "tech" in general. | |||
| My goals for myself are to enjoy more regular collaboration, and thereby hopefully faster professional/personal growth, and to get to the point where it's easier and less stressful to take an occasional vacation of modest length. I hope these and other intangibles also materialize for everyone involved, in addition to their own goals. Some very specific areas I'm interested in improving are: | |||
| - communication | |||
| - project planning/management | |||
| - sales | |||
| - automated testing | |||
| - modern JS stack (React/Vue/whatever) & deployment infrastructure (k8s, docker-compose, serverless, etc) | |||
| - it'd be cool to have a chance to learn Go or Rust (but I will happily stay in bash, python, js, etc for as long as I live if not) | |||
| I'd like to draw some hard lines and some firm (but bendable with deliberation) lines in terms of clientele: | |||
| - Hard lines: | |||
| - no adtech | |||
| - no Israel | |||
| - no police/prison/military/intelligence | |||
| - Firm-ish lines: | |||
| - no bitcoin/ethereum but willing to look closely at other coins/blockchains with a critical but open mind. | |||
| - "free speech" makes me skittish these days. | |||
| - "we're just a platform and not responsible for individual content" is not OK with me in general but open to discussion. | |||
| - Ideal targets: | |||
| - Co-ops (principle #6) | |||
| - non-profit/left-wing and left-ish/progressive orgs | |||
| - Open-source/Free Software/open-core/etc (though my personal licensing preference these days is complicated and still under review) | |||
| - Public benefit / B Corps | |||
| - the good parts of government (social security, medical care, etc) | |||
| - OK, Fine: | |||
| - most anything else, I guess! | |||
| Speaking of principle #6, the 7 cooperative principles are definitely guidelines for what I envision, if that wasn't already clear. | |||
+ 66
- 0
posts/edit-last-commit.md
View File
| @ -0,0 +1,66 @@ | |||
| --- | |||
| title: Bash One-liner to Edit All Files from a Git Commit | |||
| description: a quick bash/git trick to reopen all files from a given commit. also an encouragement to make yourself little bash scripts. | |||
| created: 2021-03-01 | |||
| tags: | |||
| - bash | |||
| - git | |||
| - programming | |||
| --- | |||
| Over the years I've greatly enjoyed learning how to simplify common actions in the terminal. I want to share a quick, simple example of a handy little helper-script, and encourage you to add these kinds of helpers to your workflow. It's a great way to improve or maintain your Bash skills, and anyway making a task easier or faster is probably the foundational joy of programming. | |||
| --- | |||
| I found myself in a situation last week where I wanted to quickly reopen all the files from my last Git commit. It's easy to do this, but in my experience one of the difficulties of Bash is knowing what keywords to search for to find help, so I'm going to put the pieces of this together one by one, with some other helpful tricks, so that you don't have to wait as long to find each piece as I did. | |||
| ## Command Substitution | |||
| One feature of Bash that I took far too long to fully discover and understand, but now can't live without, is command substitution. In short, it's a shortcut to simplify using the output of evaluating a command as input to some other command. This is possible with pipes, but often more verbose. The short form is simple -- `$(command)`. For example, one might be looking around for something in a project dir with `rg`[^1] - `rg 'function_name'` - and then decide it's time to edit. `rg` lists matching files with the `-l` switch, so you can invoke `vim $(rg -l 'function_name')` to open all the search results as vim buffers. This could be shortened or further manipulated with history commands. I've found a good quick-reference for those on StackExchange[^2]; do yourself a favor and give it a look if you aren't familiar, but I won't go into detail here as we're already getting a bit afield. | |||
| ## Listing files from a commit | |||
| So, if we have a command that can produce a list of files from the last commit with no other data, we know how to easily bring them into vim. Luckily we have options! When I set this up I definitely just found the relevant StackOverflow[^3] and ran with it, but I hate to miss an opportunity to recommend spending some time with the Git docs[^4], where with a little determination and trial-and-error you could find your way to the right answer as well. The recommended answer that we'll use here is: `git diff-tree --no-commit-id --name-only -r <commit-ish>` | |||
| ## A simple Bash script | |||
| Now it's almost as simple as combining those two pieces! Yes, `vim $(git diff-tree --no-commit-id --name-only -r HEAD)` works, but it's verbose and a bit tricky to remember. We could fix this with an alias in `.bashrc` or `.bash_profile` -- `alias edit_last_commit=vim $(git diff-tree --no-commit-id --name-only -r HEAD)` -- cool! BUT, what if we want to pull up some other set of changes? I'm not sure if this is possible with an alias[^5], but it definitely is with a little script. | |||
| I don't know if there's a more recommended or standard way to organize scripts like this[^5], but my approach is to make a dir at `~/scripts` and make sure it's on my `$PATH`. So, we'll put this little buddy at `~/scripts/edit_last_commit`. | |||
| The only other detail to comment on here is one I've elided so far: how to refer to whatever set of changed files we want to edit. What I'm getting at is, what is a <commit-ish>? It's... something that looks kinda like a commit! For a very detailed explanation we can turn again to the Git documentation[^6] but in short, most any way of identifying "the set of files last changed *here*" will work. | |||
| That's a lot of bits and bobs! I hope at least one of them is new and useful to you. Let's put them all into a bash script, with some annotation: | |||
| ```bash | |||
| #!/bin/bash # shebang line to ensure we end up evaluating this as bash! | |||
| set -e # only here out of habit; this ensures the script will exit on errors rather than causing mayhem (unexpected behavior) | |||
| if [[ -z "$1" ]]; then # if the first argument to the script is null (in other words, called with no args) | |||
| commitish="HEAD" # default rev is HEAD | |||
| else | |||
| commitish="$1" # but if the first argument *does* exist, use it! | |||
| fi | |||
| vim $(git diff-tree --no-commit-id --name-only -r $commitish) | |||
| ``` | |||
| Once the script is saved, give it the ol' `chmod +x`[^7] and you're all set. | |||
| I'll say it again: Bash has some damn near impenetrable and difficult-to-search syntax. Please do take a look at documentation for `set -e`[^8] or that `if` statement[^9] to learn more; these are bread-and-butter for small helpful scripts such as this one so it's worth understanding them and related options (`set -x` can be very handy too!) | |||
| ## Conclusion | |||
| I have called this script "simple" but it's only simple to me because I've spent years muddling about and haphazardly learning about these components along the way. If this is helpful to you, I'm so glad and I hope you can do more, faster for not having to piece all of this together yourself. If you've been muddling longer than me and have suggestions for improvements? I'd love to hear about them, within reason[^10]. | |||
| [^1]: [ripgrep, my current favorite grep-alike](https://github.com/BurntSushi/ripgrep) | |||
| [^2]: [What are your favorite command line features or tricks? - Unix & Linux StackExchange](https://unix.stackexchange.com/questions/6/what-are-your-favorite-command-line-features-or-tricks/67#67) | |||
| [^3]: [How to list all the files in a commit? - StackOverflow](https://stackoverflow.com/questions/424071/how-to-list-all-the-files-in-a-commit) | |||
| [^4]: I find that I'm constantly re-learning the value of spending some time reading documentation, manual pages, etc. for commonly used tools - for me, recently this means git, tmux, and vim - so, here's the [Git Book section on viewing commit history](https://git-scm.com/book/en/v2/Git-Basics-Viewing-the-Commit-History), and I strongly recommend taking some time now and then to read up on the amazing tools at your disposal! | |||
| [^5]: If you *do* know, I'd be glad to hear about it! | |||
| [^6]: [gitrevisions - Git Reference](https://git-scm.com/docs/gitrevisions) | |||
| [^7]: `chmod +x $filename` makes $filename executable for all users! probably fine on your own computer, but better to be more specific with permissions on other systems, to maintain a habit of care around possible security issues. | |||
| [^8]: [The `set` Builtin - GNU Bash Manual](https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html) | |||
| [^9]: [Bash Conditional Expressions - GNU Bash Manual](https://www.gnu.org/software/bash/manual/html_node/Bash-Conditional-Expressions.html#Bash-Conditional-Expressions) | |||
| [^10]: please don't tell me I ought to use emacs or zsh, for example | |||