Highly extensible software like Emacs, Vim, and Neovim tend to grow their own package managers. A software developer, for example, might want to install editor plugins that hook into a particular programming language's linter or language server. The programmer's text editor is therefore extended to support managing additional software to extend the text editor. If this loop continues for too long, the programmer's editor becomes more delicate and complex. The remedy for this problem is to manage software using dedicated tools apart
If you are getting this in gdb on macOS while trying to run a program:
Unable to find Mach task port for process-id 57573: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))
- Open Keychain Access
- In menu, open Keychain Access > Certificate Assistant > Create a certificate
- Give it a name (e.g.
gdbc
)
int doubler(int x) { | |
return 2 * x; | |
} |
It's now here, in The Programmer's Compendium. The content is the same as before, but being part of the compendium means that it's actively maintained.
#!/bin/sh | |
command="${*}" | |
printf "Initialized REPL for `%s`\n" "$command" | |
printf "%s> " "$command" | |
read -r input | |
while [ "$input" != "" ]; | |
do | |
eval "$command $input" | |
printf "%s> " "$command" |
# In order for gpg to find gpg-agent, gpg-agent must be running, and there must be an env | |
# variable pointing GPG to the gpg-agent socket. This little script, which must be sourced | |
# in your shell's init script (ie, .bash_profile, .zshrc, whatever), will either start | |
# gpg-agent or set up the GPG_AGENT_INFO variable if it's already running. | |
# Add the following to your shell init to set up gpg-agent automatically for every shell | |
if [ -f ~/.gnupg/.gpg-agent-info ] && [ -n "$(pgrep gpg-agent)" ]; then | |
source ~/.gnupg/.gpg-agent-info | |
export GPG_AGENT_INFO | |
else |
Authorization and Authentication are hard. when you only have to implement them once (as you do within a monolith) instead of over and over again, it makes the developer happy :-), and maybe leads to less implementation failures.
When you have a bunch of microservices, this is something that has to be considered.
Implement it once or in every microservice, or something in between?
This is how I configured the deploy of my rails apps to AWS Elastic Beanstalk through CircleCI 1.0.
If you are using the Circle CI 2.0, take a look at this article from ryansimms
On Project Settings > Environment Variables add this keys:
- AWS_ACCESS_KEY_ID
- AWS_SECRET_ACCESS_KEY
The aws user must have the right permissions. This can be hard, maybe, this can help you.
#include <stdio.h> | |
#include <stdlib.h> | |
#include <string.h> | |
int addi(int a, int b) { | |
return a + b; | |
} | |
char *adds(char *a, char *b) { | |
char *res = malloc(strlen(a) + strlen(b) + 1); |
Please petition Github to support HTTPS on github pages: https://github.com/contact
Here's what I wrote:
Obviously, a lot of people want HTTPS for github pages:
Until recently, that would be difficult to implement but, as it turns out, the implementation is pretty much complete: