Gemma Black gemmadlou

Accepting an invitation, from inside the app

Context

Someone invites you to their workspace. You get an email, you sign up, you verify. Now you need to say yes — and the only "yes" button in the whole repo is on a page of the account website (services/web, account-page.vue). If you are sitting in the browser app, signed in, looking at your workspace list, there is no way to accept. You have to know a separate website exists and go there.

This is the one finding that survived §78's superseded fold-the-account-site plan. It has nothing to do with which front-end owns sign-up; it is true whether or not services/web exists. Notepad: notepad/78-invitations-in-app.md.

Scope, confirmed: browser only. apps/desktop is pinned to one workspace (tauri.ts:54 → tenantSwitching: { kind: 'unsupported' }), so joining a second one is meaningless there. The block renders only where switching is supported. On desktop this plan changes nothing, and that is stated rather than papered over.

Multiple SSH Keys settings for different github account

create different public key

create different ssh key according the article Mac Set-Up Git

$ ssh-keygen -t rsa -C "your_email@youremail.com"

Install MySQL

See what formula are available.

brew search mysql

==> Formulae

Methods of Signing with GPG

There are now two ways to approach this:

Using gpg and generating keys
Using Kryptonite by krypt.co

This Gist explains how to do this using gpg in a step-by-step fashion. Kryptonite is actually wickedly easy to use-but you will still need to follow the instructions

For using a GUI-based GIT tool such as Tower or Github Desktop, follow the steps here for signing with either GPG or Krypt.co.

	{
	frankenphp
	}

	https://example.dev {
	# setup tls internally
	tls internal

	# Set the webroot to the public/ directory
	root * public/

	---
	- name: Deploy Laravel Application with Zero Downtime
	hosts: web
	become: yes
	vars:
	app_name: "domain"
	deploy_user: deployer
	deploy_group: www-data
	deploy_dir: "/var/www/{{ app_name }}.com"
	local_app_dir: "{{ playbook_dir \| dirname \| dirname }}"

	server {
	listen 80 default_server;

	server_name example.com www.example.com;

	access_log /srv/www/example.com/logs/access.log;
	error_log /srv/www/example.com/logs/error.log;

	root /srv/www/example.com/public;
	index index.php index.html;

	<?php
	namespace App\Features;

	use App\Features\FirstTask;
	use App\Features\SecondTask;
	use Illuminate\Pipeline\Pipeline;

	// Naming things is hard ... So, this is a class called `ProcessClass` that `run()` some text ¯\_(ツ)_/¯

	class ProcessClass

	#!/bin/bash
	# Sometimes you need to move your existing git repository
	# to a new remote repository (/new remote origin).
	# Here are a simple and quick steps that does exactly this.
	#
	# Let's assume we call "old repo" the repository you wish
	# to move, and "new repo" the one you wish to move to.
	#
	### Step 1. Make sure you have a local copy of all "old repo"
	### branches and tags.

	# Use envFrom to load Secrets and ConfigMaps into environment variables

	apiVersion: apps/v1beta2
	kind: Deployment
	metadata:
	name: mans-not-hot
	labels:
	app: mans-not-hot
	spec:
	replicas: 1