家のRaspberry Pi 2 Model BにSoftetherでVPNを構築
海外に来てから家のNASにアクセスしたりするためにVPN環境を構築した。
自宅には家族しかいないので、万が一ネットワーク設定ミスったりしたらサーバーにアクセスできなくなってしまうので慎重に作業した
いくつか日本語の記事を読んだが、最終的にサーバー設定はWindows用のGUIアプリを使ってたのでコマンドで設定できる方法を模索した。
後から見てみたら、Mac用のGUIアプリも公式に用意されていたのでそっちを使う方法でもよかったのかもしれない
以下を参考にしたらサクッと構築できた。すごい
Linux上にSoftether構築をコマンドでやる方法
https://linuxconfig.org/setting-up-softether-vpn-server-on-ubuntu-16-04-xenial-xerus-linuxLinux上にSoftether構築をコマンドでやる方法(日本語の記事)
http://qiita.com/showwin/items/92861057a8b62611444dAndroidからの接続方法
http://ja.softether.org/4-docs/2-howto/L2TP_IPsec_Setup_Guide/3Softetherのコマンド(vpncmd)の使い方(公式)
https://ja.softether.org/4-docs/1-manual/6/6.2SoftEtherの管理コマンドリファレンス(公式)
https://ja.softether.org/4-docs/1-manual/6._Command_Line_Management_Utility_Manual/6.6_VPN_Tools_Command_Reference
Goにおけるreflectまわり調べた
javaとScalaとGoでそれぞれclass、型、インターフェース、メソッドの用語の意味が微妙に違うから混乱する
なんなら型クラスとかある
なぜ遅いか
- 静的な型付けがされていたり、コンパイルされていたりする言語でもリフレクションアクセスの場合は
interpretiveに解釈されるから
遅い reflectionは
メモリアロケーションが多く発生するため
遅い 恐らく、静的型且つ、コンパイル型であるGoにとってダイナミックにメモリアロケーションをするのは特にコストが高いのかも)makeFunc()を見てみると、makeFunc.go#62で呼び出しているfuncLayout()の処理が重そう(完全に雰囲気だけど)
funcLayout()は渡された汎用型(rtype)を「関数型だったら」「インターフェイス型だったら」とかいっこずつ分解していっって、値型によっても一つ一つみてレイアウト情報を取得してるっぽい。
if runtime.GOARCH == "amd64p32" {
みたいなコードもあるのでCPUアーキテクチャによる分岐もはいってる雰囲気
いかにも重そう(な雰囲気)型情報を取得するときは、ValueOf()でValue型に変換して、Type()を呼び出す
unsafe.Pointerを使って、型の種類ごとに処理が書いてある(Funcならこれやる、Interfaceならこれやるみたいな)
type.uncommon()でFuncなのかArrayなのか、Sliceなのか…を分岐で判断してる
それに応じてruntime/type.goのresolveTypeOff()でごにょごにょしてるが、reflectOffsLock()という関数を呼び出しているので、もしかしたらプロセスのメモリ空間のテキストセグメントにアクセスするときに、goroutine同士のメモリ競合しないようにロックを取得しているのかな?
参考
なぜリフレクションは遅いのか
http://postd.cc/why-is-reflection-slow/
golangのある生活
http://ameblo.jp/principia-ca/entry-11929774278.html
The Laws of Reflection
https://blog.golang.org/laws-of-reflection
How slow is Go’s reflection effectively?
https://groups.google.com/forum/#!topic/golang-nuts/HcfutSkJVoY
Unsafe in Go 甘美な世界
https://techblog.ca-reward.co.jp/2016/08/post-117.html
goroutineを調べたときに深掘りしたときに調べたまとめ
並行処理プログラミングのモデル
Shared memory
いわゆるプログラミング言語のランタイムによるアプリケーションスレッド(グリーンスレッド)である
同じプロセス(LWP)内でランタイムによりスイッチされながら実行される並行化の仕組みなので、マルチコアにスケールはしない
[同じプロセス(LWP)内で動く = メモリ空間を共有する]ためグローバルオブジェクトなどへの共有メモリアクセスを制限するため、ランタイム側で実行中のアプリケーションスレッドにロックを取得させている
ロックを取得・開放を繰り返して、スイッチさせながら複数のアプリケーションスレッドを実行しているためCPUバウンドの処理の場合はパフォーマンスは改善しない(むしろスイッチコストがかかるため悪くなる)
ただし、IOバウンドの処理の場合は、IO waitの時にロックが開放されるため効率よく並列化できる。
ネットワークIOやファイルIOを多重化する場合は、アプリケーションスレッドでも効率的に並列化できる
Message passing
Shared memoryがメモリアドレスを共有するのに対して、Message passingは共有しない
データをメッセージとしてやり取りすることにより、送り手と受け手の中でのみメモリ空間を論理的に管理する(送り手と受け手のメモリ空間をライブラリレベルで論理的に管理する)
actor modelが有名
Implicit Interaction
並列化をプログラミングコードレベルでは意識せずに、コンパイラやインタプリターで暗黙的に実現する。 プログラマは並列化を意識せずにコードを書くが、コンパイル時に並列実行できるようなコードに変換される(インタプリタの場合は実行時)
並列プログラミングにおける問題のカテゴリ
タスク並列化
データ並列化
暗黙的な並列化
用語
コルーチン
サブルーチンが手続き全体を処理する塊に対して、途中で明示的に実行を停止して制御を返すことができる処理
Pythonで言うyield文を使ったジェネレータ的な
goroutine
CSP (Communicating Sequential Processes)という理論にもとづいている
- goroutineアプリケーションスレッドのスケジューリング
- スタック管理
- ネットワークIO
goroutine は並行性(並列性ではない)を扱いやすくするための機能です。複数スレッドで独立した関数を多重化して coroutine のように実行するというアイデアは以前からありました。 ブロッキングするシステムコールを呼び出したときなどで、ある coroutine がブロックするとき、ランタイムは自動的に OS の同一システムスレッド上で他の coroutine が一緒にブロックされないように、実行可能な別のスレッド上に移動します。プログラマがこれを意識しない、これが重要な点です
軽量スレッドと捉えるよりも、内部的にはジェネレータみたいな呼び出し待ちををランタイムがスケジューリングしてるイメージなのかな。
だからcoroutineをもじって、goroutineなのかな
http requestハンドリングでのgoroutine
golangの標準パッケージのhttp serverの実装はgoroutine per request(connection)になってた(http/server.go#2668)
libuvのような非同期IOを使ったコールバックよりも、goroutineによる並行化の戦略をとってるっぽい
そういうもんなんだろうか、、、?
参考
Parallel programming model
https://en.wikipedia.org/wiki/Parallel_programming_model
Go 言語の goroutine と channel についての考察
http://qiita.com/izariuo440/items/9e1b1faabcee6e2e94c0
イベントループなしでのハイパフォーマンス – C10K問題へのGoの回答
http://postd.cc/performance-without-the-event-loop/
Coroutine
http://qiita.com/fujimisakari/items/811e350cbaeb45b6165e
Go の並行処理
http://jxck.hatenablog.com/entry/20130414/1365960707
「サーバ書くなら epoll 使うべき」は、今でも正しいのか
http://developer.cybozu.co.jp/archives/kazuho/2009/09/epoll-bac0.html
Linuxにおけるプロセス/スレッドの調査とか学習とか
概念的・理論的な意味におけるプロセスとスレッド
プロセスとはプログラムコードやメモリ空間などを含めた実行処理のインスタンスである
スレッドとはプロセス内でメモリを共有し、並行化するためのより細かい単位である
Linuxにおけるプロセスとスレッド
プロセスは概念的なプロセスをそのまま実装されたもの
プロセス内で並列・並行化するためのスレッドは2つの意味がある
軽量プロセス(LWP)
プロセス内でスレッドを実現するが、スレッドの実行スケジュールはOSのスケジューラが行う なので、OSスケジューラから見たら、プロセスとスレッド(LWP)は同じ単位になる
OSのスケジューラを使うので、マルチコアにおけるCPU資源の割り当てが可能ユーザースレッド(アプリケーションスレッド)
ユーザ空間で実装
されたスレッド機構
実際はプロセス - LWP - ユーザースレッド
という紐付けになる
ユーザ空間で実装されたランタイムでスケジューリングされるので、プロセス内でのタスク切り替えになるのでシングルコアでしか動かない
なので、 Linux上でスレッドを使って並行・並列化するという文脈の時は
- LWPを多重化すれば、並列化(CPUコアでスケールする)
- ユーザースレッドを多重化すれば並行化(シングルコアでタイムスライス)
ユーザー空間上の実装で並列・並行化可能という意味で、この2つの方法を区分けせずに ユーザー(空間上の)スレッド
と表記するケースがある
プロセススケジューラについて
プロセススケジューラを呼び出されるタイミングは
- CPUによる200msごとの割り込みがあった場合
- 実行中のスレッドが明示的にスケジューラを呼び出した場合
- 他にもあるっぽい
これらのタイミングでプロセススケジューラが呼び出されて、その時に一番優先順にが高いプロセスにタイムスライスが割り当てられる
スケジューラはCPU割り当てのスイッチも行うことから、カーネルモードで実行される
カーネルモードとユーザーモードについて(CPUモード)
CPUのアーキテクチャ(x86とか)で実装されている実行権限コントロールの仕組み
カーネルモード = 特権モード = マスターモード = スーパーバイザーモード = システムモード
と状況によって呼ばれ方が違う
システムコールなどを通じてデバイスアクセスしたりする時はカーネルによってスレッドをカーネルモードに切り替える。
この切替が行われないままのユーザーモードだとデバイス操作などに必要なカーネルメモリ空間へのアクセスはできない(例外が発生する)
カーネルモードのユーザープロセス(スレッド)
のことを カーネルスレッド
を表記する場合があるが、状況によっては正解、、、?
カーネルスレッドはカーネルメモリ空間で実行される = カーネルモードのCPUで処理されているスレッドはカーネルメモリ空間へアクセスできる
と同意っぽい
カーネル空間/ユーザー空間について
メモリ上においてカーネルモードのプロセスのみがアクセスできるメモリ空間
カーネルスレッドについて
PIDが0のinitや割り込み処理などを行うスレッド
ユーザープロセス(スレッド)と同じようにスケジューラによってCPU割り当てされる
カーネルスレッドはメモリ空間を固定で割り当てられていない
そのためスケジューラによって切り替わる直前のユーザープロセスのユーザーメモリ空間を使う(そのためカーネルスレッドのタイムスライスの時は毎回メモリ空間が異なる)
カーネルスレッドという言葉を使う時に OSカーネルの処理を専門で扱うスレッド
を指す場合と カーネルモードのユーザープロセス(スレッド)
を指す場合があるので注意(ここでは前者の意味)
プロセスと軽量プロセス(LWP)とスレッドと
プロセスはプログラムコードやスタック領域などを含めた実行状態のインスタンスみたいなもの
プロセス毎に違うメモリ空間が割り当てられているため、お互いのプロセスのメモリ空間には通常アクセスできない(そのため不具合があってもプロセス間で伝搬しない)
スケジューラーによってプロセスを切り替える時に実行中のコンテキスト(スタックなど)を一度保存したあと、切り替え後のプロセスも保存してあったコンテキストを復元して処理を続行する。
そのため切り替えるたびにこの処理が必要なため切り替えコストが高い(これをコンテキストスイッチが高い)と呼ぶ
スレッドはプロセスと違い、一つのメモリ空間を使って生成される。(プロセスというメモリ領域に複数のスレッドを生成することが可能)
そのため、上記のようなメモリを退避が不要なためコンテキストスイッチのコストが低い
Linuxではプロセスを生成するときにLWPとして生成することができる。
これは実質スレッドだが、スケジューラはプロセスとして扱うのでタイムスライスのコントロールはOSのスケジューラが行う
言語ごとのプロセスとスレッドの扱いについて
go(goroutine)やpython
- プロセス ┃-LWP(ユーザー(空間上の)スレッド) ┃ └ユーザースレッド(アプリケーションスレッドと呼ぶ場合も): goroutine, python Thread ┃ └ユーザースレッド(アプリケーションスレッドと呼ぶ場合も): goroutine, python Thread ┃ └ユーザースレッド(アプリケーションスレッドと呼ぶ場合も): goroutine, python Thread
いわゆるグリーンスレッドを扱う言語
一つのプロセス(=LWP)上で、言語ランタイムによって擬似的にスレッドを生成する。
pythonや以前のRubyの場合はGIL(Global Interpreter Lock)という機構があるためパフォーマンスが出づらい(IO多重化には有効っぽい?)
pthreadやJVMのThreadの場合
- プロセス ┃-LWP(ユーザー(空間上の)スレッド) ┃ └アプリケーションスレッド(ユーザースレッドと呼ぶ場合も): pthread, JVM Thread ┃-LWP(ユーザー(空間上の)スレッド) ┃ └アプリケーションスレッド(ユーザースレッドと呼ぶ場合も): pthread, JVM Thread ┃-LWP(ユーザー(空間上の)スレッド) ┃ └アプリケーションスレッド(ユーザースレッドと呼ぶ場合も): pthread, JVM Thread
いわゆるネイティブスレッドを扱う言語
LWPとアプリケーションスレッドが1:1なので、タスクスケジュールはOSの機構を使う
参考
Linuxプロセスについて スケジューリングとプロセスの扱いについて勉強になった http://archive.linux.or.jp/JF/JFdocs/The-Linux-Kernel-5.html
Linux全般について全体的にざざっと読み直して理解を深めた http://archive.linux.or.jp/JF/JFdocs/The-Linux-Kernel.html#toc5
カーネルスレッドとは http://wiki.bit-hive.com/north/pg/%A5%AB%A1%BC%A5%CD%A5%EB%A5%B9%A5%EC%A5%C3%A5%C9%A4%C8%A4%CF
プロセスとスレッドのコンテキストスイッチのコストの違い http://d.hatena.ne.jp/naoya/20071010/1192040413
Linuxスケジューラの実装について http://qiita.com/nhiroki/items/2fa7bb048118145b00cd
M:Nスレッドモデルについて https://subtech.g.hatena.ne.jp/mala/20090920/1253447692
アドレス空間 https://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%89%E3%83%AC%E3%82%B9%E7%A9%BA%E9%96%93#.E3.83.A6.E3.83.BC.E3.82.B6.E7.A9.BA.E9.96.93
CPUモード https://ja.wikipedia.org/wiki/CPU%E3%83%A2%E3%83%BC%E3%83%89
スレッド ここも混乱した ユーザースレッドとカーネルスレッドの項で「ユーザ空間で実装されたスレッド機構をユーザースレッド、特に仮想機械上で動くものをグリーンスレッドと呼ぶ」とあるが、これは今回で言うアプリケーションスレッドのこと https://ja.wikipedia.org/wiki/%E3%82%B9%E3%83%AC%E3%83%83%E3%83%89_(%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF)
プロセスとスレッド やっぱり混乱する http://hivecolor.com/id/162
ユーザースレッドとカーネルスレッドがあいまいな例 ユーザースレッドとカーネルスレッドの説明と定義があいまいでわかりづらい。 恐らくここで言ってるユーザースレッドはランタイムで実装しているアプリケーションスレッドのことっぽい。 カーネルスレッドについての記述はそのもの自体はあってるっぽいけど、本当の意味でのカーネルスレッド(initや割り込みなど)と対比させるならユーザープロセス(スレッド)と対比させないと混乱する https://books.google.co.jp/books?id=nFlhOc3_G78C&pg=PA256&lpg=PA256&dq=%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E3%82%B9%E3%83%AC%E3%83%83%E3%83%89&source=bl&ots=EFflK1Dz55&sig=4mZ4Hj-27zV_sqDh1B_wR-a7Fzk&hl=ja&sa=X&ved=0ahUKEwjFuJjm-tnSAhVEwLwKHXw_APE4FBDoAQhTMAw#v=onepage&q=%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E3%82%B9%E3%83%AC%E3%83%83%E3%83%89&f=false
JavaにおけるスレッドとOSスレッドのマッピング http://www.acroquest.co.jp/webworkshop/JavaTroubleshooting/column_004Main.html
相談
桑野さん(@kuwa_tw)
JavaにおけるOS上のスレッドの取り扱い
Threadのメモリモデルを色々調べていくうちにJavaのスレッドでOSスレッドとどうやって紐付いてるんだろうと思って調べた。
JavaにおけるTheradスケジューラはOSに依存するみたいな説明がされているが、要はJVMプロセス内でOSスレッドを生成してそれをwrapしている。
知識としては知っていたけど、改めて確認してみたかったメモ
public class Main { public static void main(String args[]) throws Exception { Thread.sleep(1000 * 60 * 60); // プロセス終了しないように止めておく } }
javacしてjava Mainでjavaプロセス起動してからPID確認
root@dc4d74fd6f08:/# jps 5684 Jps 5498 Main ←ここにいる
まずはjstackでjava threadを確認
root@dc4d74fd6f08:/# jstack 5498 | grep nid "Attach Listener" #9 daemon prio=9 os_prio=0 tid=0x00007f29a0001000 nid=0x15ba waiting on condition [0x0000000000000000] "Service Thread" #8 daemon prio=9 os_prio=0 tid=0x00007f29dc0c0000 nid=0x1587 runnable [0x0000000000000000] "C1 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x00007f29dc0b0800 nid=0x1586 waiting on condition [0x0000000000000000] "C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007f29dc0af000 nid=0x1585 waiting on condition [0x0000000000000000] "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007f29dc0ac000 nid=0x1584 waiting on condition [0x0000000000000000] "Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00007f29dc0aa000 nid=0x1583 runnable [0x0000000000000000] "Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007f29dc083800 nid=0x1582 in Object.wait() [0x00007f29c5a50000] "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007f29dc07f000 nid=0x1581 in Object.wait() [0x00007f29c5b51000] "main" #1 prio=5 os_prio=0 tid=0x00007f29dc009800 nid=0x157b waiting on condition [0x00007f29e36ea000] "VM Thread" os_prio=0 tid=0x00007f29dc077000 nid=0x1580 runnable "GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007f29dc01f000 nid=0x157c runnable "GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007f29dc020800 nid=0x157d runnable "GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00007f29dc022000 nid=0x157e runnable "GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00007f29dc024000 nid=0x157f runnable "VM Periodic Task Thread" os_prio=0 tid=0x00007f29dc0c2800 nid=0x1588 waiting on condition root@dc4d74fd6f08:/# jstack 5498 | grep nid | wc -l 15
jstack的には15個のスレッドがあった
次にpsコマンドでOSスレッドを確認
root@dc4d74fd6f08:/# ps -feL | grep "java Main" UID PID PPID LWP C NLWP STIME TTY TIME CMD root 5498 1 5498 0 16 11:36 ? 00:00:00 java Main root 5498 1 5499 0 16 11:36 ? 00:00:00 java Main root 5498 1 5500 0 16 11:36 ? 00:00:00 java Main root 5498 1 5501 0 16 11:36 ? 00:00:00 java Main root 5498 1 5502 0 16 11:36 ? 00:00:00 java Main root 5498 1 5503 0 16 11:36 ? 00:00:00 java Main root 5498 1 5504 0 16 11:36 ? 00:00:00 java Main root 5498 1 5505 0 16 11:36 ? 00:00:00 java Main root 5498 1 5506 0 16 11:36 ? 00:00:00 java Main root 5498 1 5507 0 16 11:36 ? 00:00:00 java Main root 5498 1 5508 0 16 11:36 ? 00:00:00 java Main root 5498 1 5509 0 16 11:36 ? 00:00:00 java Main root 5498 1 5510 0 16 11:36 ? 00:00:00 java Main root 5498 1 5511 0 16 11:36 ? 00:00:00 java Main root 5498 1 5512 0 16 11:36 ? 00:00:00 java Main root 5498 1 5562 0 16 11:38 ? 00:00:00 java Main root@dc4d74fd6f08:/# ps -feL | grep "java Main"| wc -l 16
ps的には16個あった
psコマンド的にはjstack比べてスレッドが一個多いのは
>root 5498 1 5498 0 16 11:36 ? 00:00:00 java Main
これが大元のjava親プロセスでメインスレッドを作るときにforkして子プロセスを作ってるっぽい(PIDとLWPが同じなので)
- 1Processは1CPUで実行される
- なので概念的にはProcessの中にいくらThreadを作成して並行化しようが、1CPUしか使わない
- そこでLinuxとしてはLWP(Light Weight Process)としてメモリ共有したプロセス(軽量プロセス)を生成し、Threadとして扱う
- 昔のLinuxはLWPがなかったので、単なるThreadだったのでマルチコアで多重スレッドにはできなかった
- 実際、上記のps -feLの結果確認するとLWPのIDが全部違うのでOSスレッド = 軽量プロセスということになっている
スッキリした
マネジメントの秘伝のタレ
今回は私が今までチームマネジメントやヒューマンマネジメントを通して学んだTIPSを整理してみたいと思います。
マネジメント(≒コミュニケーション)を支える技術について都度メモして、自分への戒めとして利用していたものを箇条書きにまとめました。
ある特定の状況だけでしか適用できないものが多いですが、応用はいろいろ効くと思っています。
マネジメントの立場にこれからチャレンジしていきたい人の一助になればと思ってます。
※自分向けのメモを整理しただけなので、一般的にこうあるべきという内容ではありません。
会議編
-全員の参加を促そう
全員の発言機会が均等になっているか常に意識しよう
一言でも意見を言うことによって、その議題を決めたという意識を持てる
- 自分自身(チーム自身)で決めたという感覚に落としもう
「決められたこと」ではなく、「自分たちで決めたこと」という意識を促そう
その決定が実行されなかった時に他責にしずらくなる
- 話が長い人は最後に要約を返してあげよう
「つまり〜〜ということであってますか?」
まわりが飽きてしまうと会議からの離脱が増える
要約してあげることで離脱者を引き戻すことができる
- 視界から消えよう
マネージャーに向かって話すと、複数人なのに一対一のようになってしまう
マネージャーは目を合わせない、ホワイトボードに向かう、後ろに立つ、歩き回るなどして存在を消そう
そうすれば、自然と視線がメンバー同士になる
- 話が長い人はインターセプトしよう
ペンを落とす、くしゃみをする、携帯を鳴らす、トイレに行くなどして会話を途切れた瞬間に話題を変えよう
ただ、あからさまだと失礼なので注意
- わちゃわちゃし始めたときは議論の立ち位置を確認しよう
議論が広がりすぎたときはホワイトボードに簡易マインドマップなどの関連図を書いて、全員で位置関係の認識を合わせよう
空気がけっこう引き締まる
- 空気を占拠しよう
最終的にはマネージャーが責任を持つべきなので、その意思表示のためにも率先して場の空気を占拠しよう
最初にホワイトボード前に立つ、ホワイトボードマーカーを最初に手に取るなどをすればそんな空気になる
- 個人攻撃はすぐにやめさせよう
何も生まれないし、チーム内に禍根の残すきっかけになってしまう
- メンバー同士が衝突し始めたら目線を逃がすように誘導しよう
メンバー同士で正面から目が合った状態で、議論が白熱すると言葉が荒くなったり、喧嘩腰になったりする人もいる
そんな時は、ホワイトボードやノートに書き出したり、モニターを映してみたりして全員の目線を外に逃がそう
- 誰か喋るまで待とう
喋りすぎなマネージャーは議論の邪魔
静かな空気が苦手でも誰かが喋るまで待とう
それでも喋らなかったらそもそも会議自体の内容を見直そう
- よーく観察しよう
寝てる人はいないか、飽きていないか、明らかに他の作業をしていないか常に観察しよう
- 眠たそう、寝ている人がいたらあからさまに意見を求めよう
「寝ないでください」と直接言うのはスマートじゃない
あからさまに何度も意見を求めることによって本人が気づいてくれるのを促そう
それでもだめなら休憩をいれよう
- PCを開けないように机をなくそう
「PCを開くな」や「PCを持ち込むな」と注意するのはクールじゃない
仕組みで解決しよう
- 時間をコントロールしよう
(25分 + 5分) or (50分 + 10分)のワンセット一本勝負
- 議論の決定は必ず実行しよう
実行されないと、発言しても意味がないと思われるので参加意欲が失われる
面談編
- 注意・説教はやめよう
注意する時は、必ず信頼関係が築けてから
そうでない限りは注意・説教しても何も影響しない
- 期待は伝えずに聞いてみよう
「あなたに期待されていることってなんだと思いますか?」
先に質問することでメンバーの意識とマネージャーの意識のギャップを確認しよう
- 相手のテンションを下げないようにしよう
相手のテンションを下げても何も生まれない
テンションをあげるような言葉遣いを意識しよう
- 条件反射を徹底的になくそう
カチンとすることを言われても、反射的に反論しないようにしよう
3呼吸ぐらいは置こう(短気だと思う人は5呼吸ぐらい)
もしくは、スルーしてから面談の最後にどうしても言いたかったら言おう
- 権利と義務はセットではないことを意識しよう
権利は権利、義務は義務
納税していない人でも選挙権はある
- 期待をはっきりと伝えよう
どういう人材になってほしいか誠実にはっきりと伝えよう
実際に相手のやりたいこととマッチするかは別にして、まずは伝えよう
- 徹底的に相手の立場を想像しよう
どのように伝えられたらテンションがあがるか?
どのような言葉を使われたら気分が悪いか?
- うわべの会話はやめよう
うわべで話していると相手は必ず気づく
本心から興味を持っていないことは必ず伝わる
うわべで褒めても必ず見抜かれる
そのためには日頃から観察しよう
- 指示ではなく、提案をしよう
条件、目標、作業など相手が決めきれない時は複数提案してあげよう
ちょっとの違いでもいいから複数だそう
"選択した" という行為によって、自分で決めたことになる
- 相手の心を揺さぶろう
扇動的な言葉を使って、相手の心を揺さぶろう
そこにモチベーションを上げるヒントがある
- 評価しないように意識しよう
マネージャーがその人の全てを評価できると思うことはおこがましい
評価はさまざまなプロセスで最終的に決まる
面談しただけの印象で固定観念に落とさないようにしよう
- 直接プレッシャーをかけないようしよう
直接的なプレッシャーは人を潰すだけ
期待をする、期待をされることでプレッシャーは相手の中で勝手に醸成される
マネジメントは技術です。
本もたくさん出ていますし、バイブルと言われているような有名な本もあります。
知識をつけて、実践して、失敗して、工夫して、身につけていくものです。
プログラミングと全く同じですね!
wordpressのdockerコンテナからRDSに接続する
今度はRDSに接続してみる。
RDSはとりあえずdevでぽちぽち立ち上げ。
mysql -h ${RDS ENDPOINT} -P 3306 -u ${RDS USER} -p
で接続できることを確認。
接続できない時は立ち上げたVPC上のSecurity Groupの設定で接続元(この時はローカルのMacから接続してたので自宅のグローバルIP)とポートを許可する
RDSに接続できることを確認できたらwordpressのコンテナ起動オプションに
https://hub.docker.com/_/wordpress/
に従い -e オプションで接続先のDB設定を追加する
docker run --name wordpress -e WORDPRESS_DB_HOST=${RDS ENDPOINT} -e WORDPRESS_DB_USER=${RDS USER} -e WORDPRESS_DB_PASSWORD=${RDS PASSWORD} -p 80:80 -d wordpress
起動できたら前回同様にブラウザでアクセスしてみる
#dockerホストのIP確認
$ docker-machine ip wordpress >192.168.99.100
http://192.168.99.100にアクセス -> OK