+------------+-------------------+--------+
| *M* or *m* | moveto | (x y)+ |
+------------+-------------------+--------+
| *Z* or *z* | close path | (none) |
+------------+-------------------+--------+
Get Homebrew installed on your mac if you don't already have it
Install highlight. "brew install highlight". (This brings down Lua and Boost as well)
// Package main is a sample macOS-app-bundling program to demonstrate how to | |
// automate the process described in this tutorial: | |
// | |
// https://medium.com/@mattholt/packaging-a-go-application-for-macos-f7084b00f6b5 | |
// | |
// Bundling the .app is the first thing it does, and creating the DMG is the | |
// second. Making the DMG is optional, and is only done if you provide | |
// the template DMG file, which you have to create beforehand. | |
// | |
// Example use: |
これは私が支援先に提供した、1 on 1 に関するノウハウや、思いを述べたドキュメントを元にしています。企業の枠を超えて共有したいことが多いので、ここに貼ります。
- 世の中には 1 on 1 の本があるようですが、とりあえずは『1 on 1 で 何を話すのか? マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア』を読んでもらえればよいと思います (higepon さんに感謝!)。
- 1 on 1 は 1 対 1 で話すミーティングで、基本定期的にやります。上長とメンバーとの間で行うのが基本です。
- グループ/チームでのミーティングを補完するためのものです。
- みんなの前では話しづらい、込み入った内容を話します。
- チームとして行っているタスクの進捗確認に 1 on 1 を使うのは避けましょう。それは 1 on 1 の目的に沿っていません。
- 基本、「メンバーの時間」と捉えてください。メンバーが話したいこと、上長に質問したいこと、相談したいことを話す時間です。
- ですので、上長は相手の話をさえぎらず、聞くことに徹してください (話すのが得意な人、好きな人がマネージャになっている可能性が高いというバイアスに注意しましょうw)。
When hosting our web applications, we often have one public IP
address (i.e., an IP address visible to the outside world)
using which we want to host multiple web apps. For example, one
may wants to host three different web apps respectively for
example1.com
, example2.com
, and example1.com/images
on
the same machine using a single IP address.
How can we do that? Well, the good news is Internet browsers
- 日時
2024-02-01
- 作
- 資料 バージョン
2024.1
- GitHub URL
- 製品 URL
version: '2' | |
services: | |
postgres: | |
image: postgres:9.5 | |
restart: always | |
environment: | |
- "POSTGRES_USER=${POSTGRES_USER}" | |
- "POSTGRES_PASSWORD=${POSTGRES_PASSWORD}" | |
- "POSTGRES_DB=gogs" | |
volumes: |
(a gist based on the old toolmantim article on setting up remote repos)
To collaborate in a distributed development process you’ll need to push code to remotely accessible repositories.
This is somewhat of a follow-up to the previous article setting up a new rails app with git.
Set up the new bare repo on the server:
The official guide for setting up Kubernetes using kubeadm
works well for clusters of one architecture. But, the main problem that crops up is the kube-proxy
image defaults to the architecture of the master node (where kubeadm
was run in the first place).
This causes issues when arm
nodes join the cluster, as they will try to execute the amd64
version of kube-proxy
, and will fail.
It turns out that the pod running kube-proxy
is configured using a DaemonSet. With a small edit to the configuration, it's possible to create multiple DaemonSets—one for each architecture.
Follow the instructions at https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/ for setting up the master node. I've been using Weave Net as the network plugin; it see