[MEMO] katacodaでLearn Kubernetes ver3 ingress

Create Ingress Routing

Create Ingress Routing | Kubernetes | Katacoda

Ingress - Kubernetes

Ingressとは

Ingressはkubernetes外部にHTTP/HTTPSのプロトコルアクセスを公開するためのものです。もし、それ以外を公開したければ、 Service.Type=NodePortかService.Type=LoadBalancerを使うことが多いです。

前提

Ingress controlerを作る必要があります。ingress-nginxが一番有名っぽい？かな。 複数持つことも可能。ただ、複数の種類を使うのは少し難しい。

Ingress Controllers - Kubernetes

Kind ingress

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: index-ingress
spec:
  rules:
  - http:
      paths:
      - path: /indexpage
        backend:
          serviceName: index
          servicePort: 80
      - backend: # pathを指定しなければ、他全部あつかい
          serviceName: no-page
          servicePort: 80

[MEMO] katacodaでLearn Kubernetes ver2 Service / Networking

Deploy Containers Using YAML

memo

apiVersion: extensions/v1beta1
kind: Deployment
kind: Service
spec:
  type: NodePort

kubectl create -f {file}
kubectl apply -f {file}

Service

• kubernetes内部でお互いのpodsにselectorを使って、ポートを割り当てることができる。selectorを使わずに、Endpointsを使って、外部に対するアクセスを割り当てることができる。基本的には、kubenetesのpods通しでのアクセスをサポートするために使われる。

https://kubernetes.io/docs/concepts/services-networking/service/#services-without-selectors

Type

読んだことメモ。

• ClusterIP: クラスター内でアクセスできるIPを作る。デフォルト
• NodePort: StaticPortを割り当てる。外部からもそのNodeのIPとPortを指定すればアクセスできる。 :.
• LoadBalancer: クラウドプロバイダーのLBを使って外部に公開できる。（？）NodePortとClusterIPが自動で作られる
• ExternalName: サービスを外部のドメインに紐付ける。

https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types

Networking Introduction

• Cluster IP

ClusterIPは内部のPodに対して、内部からのアクセスをロードバランスするIP、ポートを用意すること

• Target Ports

portだけをしているすると、podのポートとserviceのポート両方が同じポートになる。 targetPortを指定すると、podのポートはtargetPortが利用される。

 spec:
  ports:
  - port: 8080
    targetPort: 80

• NodePort

ClusterIPとTargetPortは内部からのアクセスに対応した手法である。NodePortは外部からのアクセスを可能にするStaticIPを用意する。すべてのノードのPortを専有するかも？要検証。

spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 30080

同じポートを指定するNodePortを作ろうとしたが、エラー出たのでたぶん、全Nodeであってる。

master $ cat nodeport2.yaml  | grep nodePort -A2 -B2
  ports:
  - port: 80
    nodePort: 30080
  selector:
    app: webapp2-nodeport
master $ cat nodeport.yaml  | grep nodePort -A2 -B2
  ports:
  - port: 80
    nodePort: 30080
  selector:
    app: webapp1-nodeport
master $ kubectl create -f nodeport2.yaml
Error from server (Invalid): error when creating "nodeport2.yaml": Service "webapp2-nodeport-svc" is invalid: spec.ports[0].nodePort: Invalid value: 30080: provided port is already allocated
Error from server (AlreadyExists): error when creating "nodeport2.yaml": deployments.extensions "webapp2-nodeport-deployment" already exists

• External IPs

指定のIPのポートを外部公開し、内部のPodにアクセスする。

spec:
  ports:
  - port: 80
  externalIPs:
  - {NODE_IP}

• Load Balancer

GCPやAzure、AWSなどで外部のロードバランサーを通してLBSする機能。それがない場合でも、quay.io/munnerz/keepalived-cloud-provider:0.0.1このimageを使うことで、cloudproviderを内部に作成できるみたい。 https://github.com/munnerz/keepalived-cloud-provider

spec:
  type: LoadBalancer
  ports:
  - port: 80

リモートでのモブプログラミングの紹介

リモートチームでモブプログラミングを導入してみてうまく動き出したので、ご紹介したいと思います。モブプログラミングの記事は多いけどリモートでの記事はまだ少ないので何かしら、感じ取ってもらえると嬉しいです。最初に言っておきますが、チームの数だけモブプログラミングの形はあると思うので、参考程度に見てください。

(読書メモ) モブプログラミング・ベストプラクティス まとめ・感想 - だいごろうのブログ

モブプログラミングとは

モブプログラミングとは、１箇所にチームで集まり、１台のPCを用いて、複数に同じ課題に取り組む手法。少しだけルールがあります。

• 基本は役割が２つあり
  • ナビゲーター：問題に対し、考え、意見し、タスクの解決のために全力を注ぐ人たち
  • ドライバー：別名タイピストであり、キーボードを触る唯一の人。ナビゲーターの意見に対し、手を動かす人。
• ドライバーの人は短いサイクル（１５分とか）でローテーションする。

基本的には、これだけです。このブログが非常によくまとまってると思います。 medium.com

リモートのモブプログラミングでは、このブログが非常に良い。 www.remotemobprogramming.org

リモートにモブプログラミングは向いているのか?

この議論は非常に重要な部分だと思います。

どのモブプログラミングの本などを見ても、前提条件にチームが１箇所または１部屋に集まれることということが必ず書いてあります。これはメンバー全員が１つのタスクに集中するため、邪魔を極力減らすためなど、重要な要素です。では、リモートで、ビデオ会議で同じような環境を再現できるのか。ここができなければ、モブプログラミングの恩恵を受けることが難しくなるでしょう。

僕が導入しようと決意した経緯

リモートチームで仕事をしていると、チーム全体で知識共有やコミュニケーションがすくなることが課題となってくる。モブプログラミングの良いところは、全員でタスクに集中し、知識や手法などをオンタイムで共有しながら、お互いをより深く知ることができる点であるので、リモートチームこそ、モブプログラミングなどを用いて、より密にチーム作りをする必要があると思っている。もちろん、チャットなどでもそういったことは可能だが、やはりまとまった密な時間はその恩恵を何倍にも増やせると思っている。また、リモートだとチームメンバー同士のコミュニケーションが疎かになることがあるので、全員がお互いを”知っている”と実感するのに１役買うと思う。

僕たちのリモートモブプログラミング

リモート

リモートチームでは、チームコミュニケーションをいかに補うかが非常に重要となってくる。そのため、こういったことを意識しなければいけない。

• コミュニケーションの量を増やせるようにすること
• お互いに干渉するのを苦に思わないように状況を整理すること。
• 情報伝達を行い認識合わせを行うこと。
• ありがとうとごめんなさいを伝えること

ちなみにリモートは場所にいるメンバー限定ではなく、仕事を一緒にしたいメンバーでチーム構成できるのですごく良いです。

リモートで１箇所に集まる

ビデオ会議をするアプリというのは最近多くなっています。それらを利用して、できたらカメラでお互いの顔を見ながら会話できる状況を作ります。顔を見ながら話すことはコミュニケーションにおいて非常に重要です。顔が見えたら、モブプログラミングに集中してるか一目瞭然ですし。

ドライバーとナビゲーターをローテーションすること

これがモブプログラミングの基礎だが、意外とこれが難しい。作業に集中してると時間が経つのは早すぎる。 まず、リモートだとローテーションの時間が来たことを全員が周知することを時計などで知らせるのが意外と難しい。時間を管理する人を作ってもいいが、それ自体がその人のモブプログラミングへの集中力を下げてしまう。また、口頭で「時間だよ」っと言っても、「すぐ終わるから、ここまでやらせてくれ」っと言うメンバーがいる、それに「すぐ」には終わらない。 解決策としては、ツールを導入すると良い。チームではmobsterを使ってる。時間を測り、全画面を強制的に mobsterの画面にしてくれるし、ローテーションも管理してくれる。「だれかが、時間だよ！」っていう心理的に大変な作業を代わりにやってくれるし。画面が強制遷移すると、あ、交代だって全員思う。これを導入してから、みんな時間を守れるようになった。

Mobster - Pair and Mob Programming Timer for Mac, Windows, and Linux

リモートコントロールを利用したローテーション

リモートのモブプログラミングをしている人の多くがgitにpush/pullして、コードをドライバーから次のドライバーへ継承していくことが多い。しかし、このやり方は交代時のオーバヘッドがあるし、gitの問題によって時間をロスすることが多々ある。（gitになれない人が間違えて、他の修正をコミットしちゃったり）。また、作業時のコード以外のターミナルのログやブラウザの状態は、失われてしまう。 そこで僕たちはzoomのリモートコントロールを利用している。一人のPCをマスターPCとし、全員がそのPCとZooｍでVideo会議をする。で、作業はそのマスターPCで行い、ドライバーのローテーションに合わせてリモートコントロールを権限を移していく。こうすることで、作業中のすべてを次のドライバーへ引き継いでいる。

＊ちなみに、過去にslackがscreenheroという会社を買収し、screenheroのリモートコントロールの非常に優秀な機能を取り込んだが、複雑でメンテナンスが難しいという理由で機能の削除をした。なので、今はZoomを利用している。

Removal of remote screen control in Slack Calls – Slack Help Center

振り返り

この振り返りは非常に重要である。リモートチームではチームのコミュニケーションが密になる場面が足りないことが多いので、モブプログラミングをするとチームの問題点が浮上することがある。しかし、それはタックマンモデルの混乱期に差し掛かったといういい状態なので、ちゃんと振り返りをしチームでそれを乗り越える良い機会である。

タスクの選定はメンバーと共に。

リモートのモブプログラミングのタスク選定は慎重にメンバーと共にやったほうが良い。選び基準としては

• 全員の学習となるようなタスクである
• 全員に恩恵のあるようなタスクであるとなお良い。 また、この利用としては
• リモートでのモブプログラミングだと、それぞれ１台ずつPCを持っていることになるので、モブプログラミング中でも別作業ができてしまう。それは人の心理なので止めれないので、できるだけ全員がモチベーションが高いタスクでないと行けない。
• また、リモートでのモブプログラミングは非常に貴重な時間なので、お互いに学習になるようなタスクを選ぶことでコミュニケーションの量を蜜にし、無駄な時間を使わないようにする。
• 自分たちで選んだほうが楽しいし、より技術的なことをタスクにしやすい。

疲れることを認知する

ビデオチャットでの共同作業も、モブプログラミングも疲れる作業だ。なので、定期的に長めの休憩時間を儲けよう。リモートだと、メンバーがつかれたタイミングを知るのが難しい。あと、コーヒーのおかわりほしいし。 あと、なれない頃は長すぎるモブプログラミングは控えましょう。それだけで、モブプログラミングが苦痛なイメージになってしまうので。

素人やエキスパートのどちらでもが安心して意見できること

リモートかつモブプログラミングだと、意見を言うことに対しての敷居が上がってしまう。なので、モブプログラミングの目的は、作業を進めることだけでなく、メンバーの全員の成長も含まれていることを周知します。エキスパートに先生になってくれとお願いし、素人の意見にはまず意見を言ってくれたことに感謝する。つまりは、心理的安全性のコンセプトを理解することは非常に大事だ。

場所にこだわらない

モブプログラミングの難しい理由の一つは、定期的にメンバー全員が集まれるスペースを用意し、大きなディスプレイを用意することである。しかし、リモートの場合、ビデオチャットのアプリがあれば、ほかは何もいらない。特にMTGルームを確保するのが大変な会社だと、これは大きな恩恵になる。

より実験的に。

モブプログラミングの導入自体が実験的であるのに、リモートチームでモブプログラミングをすることはより実験的であることをメンバーにも上司にも通知しておくことが非常に大事である。そのため、メンバーからのフィードバックは定期的にたくさんもらって、常に自分たちに合う方法にたくさん改良したほうがいい。

お互い信頼すること

最後に、もっとも重要なことだが、リモートチームであること、モブプログラミングをすること両方とも信頼関係を気づくことが大事である。なんでも意見を言い合って、いけるように頑張ろう。

最後に

リモートチームでは、どのようにチーム作りをしメンバー同士の関係性を向上させるかが非常に重要になってくる。お互いを信頼し、顔が見えない中でも、コミュニケーションを取らなければいけない。モブプログラミングは、それらを改善するのに非常に重要なやり方だし、僕らのチームでも上手に作用しているし、メンバーの成長とチームの成熟に貢献していると思う。

最後に、Googleが提唱しているReWorkの「イノベーションが生まれる職場環境をつくる」の中で、コラボレーションについての記述について紹介したいと思う。

つながりとコラボレーション - 従業員が仲間を見つけやすく、協業しやすい環境をつくる。

Google re:Work - ガイド: イノベーションが生まれる職場環境をつくる

ベテラン、新入社員問わずいろいろな人とつながりを持ち、アイデアを出しやすい、成熟させやすい環境を作ることはイノベーションを生むことに繋がる。 モブプログラミングはリモートチームで、チーム内での関係性を向上させ、より面白いイノベーションを生むために非常に強いツールだと思っている。なので、もっとモブプログラミングを楽しく実行していければ、ビジネス価値やアイデアも生まれるのではないかと思っています。リモートでもそれは大丈夫です。

これからも、どんどんリモートでもモブプログラミングを実験していこうと思います。

ハッピーモビング！！

(読書メモ) モブプログラミング・ベストプラクティス まとめ・感想

読んだ本 books.rakuten.co.jp 英語版 learning.oreilly.com

モブプログラミング自体はこのブログがよくまとまってると思います。 medium.com

全体のまとめ

モブプログラミングへの感想

チームのコミュニケーションとスキルシェアリングを主として、モブプロを導入したいと思って、いろいろと調べてたらこの本がおすすめされたので、読んでみた。 実際にこの本を読みながら、チーム内で、モブプロを導入してみた。今、リモートチームということもあり、この本通りにいかないことも多くあったが、考え方自体を理解していれば、それに伴って、自チームのオリジナルのモブスタイルが生まれてきて、なかなかおもしろかった。リモートモブワークのことについてはまた、別の機会にブログにしたいと思う。あと、モブ自体は今の所うまくできており、ナリッジシェアリングやコミュニケーションの増加につながっている。フロー重視の開発に対し、正しい理解をして、なんのためにこれを導入するかを考えることが非常に重要だと思う。

本の感想

モブプログラミングとは、なにか、メリット・デメリットはなにか、導入と継続はどうするか、より効果的にモブするためにはどうするか、などに焦点をおいて、無駄な情報はなく、シンプルなので簡単に理解できるいい本だった。著者の経験や、解決策なども盛り込まれており、非常に参考になる。また、エンジニアチームという観点からもこの本は良い切り口を書いており、チームの育成を考えると、もう一度、必要なときに読みたい本。

どういった人におすすめ

今後、誰かに本を紹介するときのために、ちょっと、まとめてみる。

チームに所属していて、こういった悩みやモチベーションがある方

• プルリクのレビューが遅い、リリースまでのサイクルが遅い
• チームでスキルセットが偏ってる、スーパースペシャリスト様がいる
• ペアプロがうまくいかなかった、モブプロを導入したがしっくりこない
• タスクの終わり方がゆるゆるとしてる
• モブプロに興味がある
• 新しいことをしてみたい、チャレンジングなチームだ
• 知識をシェアする時間が非常に長い、同じことを毎度新規の人に説明してる
• 組織でのチームビルディングにコーディングが使える

印象に残ったこと

モブプログラミング

• いくつかベストプラクティスな話があるので、まずはそれに準拠するといいかも、で必要に応じてチームで変更していく。

  モブプログラミング導入の仕方

• 最初は実験として導入
• 最初の何回かは必ずレトロスペクティブ

  バットマン制度

• 名前がいいよね
• モブプログラミングを止める割り込みを止める人
• 他でも使えそうな考え方
• 割り込み自体を止めるスキルをシェア

  タックマンモデルとモブプログラミング

• もし、モブプログラミングを初めて、問題が出てきたら、それは表面化しただけなので（幸いなことに）、良いことだ。タックマンモデルで言う混乱期。

  フロー重視の進め方

• 自チームがリソース重視だったので、非常に参考になる考え方。全部フロー重視でタスクしなくとも、フロー＋リソース重視でより効率的に育つチームを作れる気がする。

  フローを維持するために

• 場所を確保
• 邪魔を減らす
• みんなが違和感ないキーボードとエディタ

  採用面接にも役に立つ

• １，２日短期採用期間を設けることが可能なら、モブプログラミングすると良いかも
• １，２時間ならペアプログラミングするのもありかも

こんな感じかな。チームで今、週１のモブプログラミングをしてみているので、また、それをベースにブログを書きたいと思います。それについて、まとめました。ぜひこちらも、読んでください。

daigorowhite.hatenablog.com

katacodaでLearn Kubernetes ver1 Clusterの作成/コンテナの立ち上げ/pod,deploy,service

katacodaで kubernetesの勉強をしていきます。このページはメモ。 www.katacoda.com

Launch A Single Node Cluster

kubernetes上にコンテナを立ち上げる

• minikube - kubernetesのクラスターをローカルテスト用に構築する
• kubectl - kuberneteのクライアント

Commnads

• minikube version
• minikube start
• minikube addons enable dashboard : ダッシュボードの追加
• kubectl cluster-info
• kubectl get pods
• kubectl run : imageから実行

kubectl run first-deployment --image=nginx --port=80 

• kubectl expose : portのフォワーディングなどできる

 kubectl expose deployment first-deployment --port=80 --type=NodePort

実際のサンプルケース

• ジョブの実行

 kubectl run first-deployment --image=nginx --port=80

• ポートのフォワーディング

 kubectl expose deployment first-deployment --port=80 --type=NodePort

• ポートを探る

export PORT=$(kubectl get svc first-deployment -o go-template='{{range.spec.ports}}{{if .nodePort}}{{.nodePort}}{{"\n"}}{{end}}{{end}}')

Launch a multi-node cluster using Kubeadm

kubernetesのクラスターをkubeadmで立ち上げる

 * kubeadm : manager cli of kubernetes

command

• kubeadm init : masterノードを立ち上げるコマンド。token初期値を渡すこともできる、ランダム生成させることもできる。productionではランダム生成させよう
• kubeadm token list : 保持しているトークンを表示できる
• kubeadm join : master ipとトークンを渡すことでkubernetesクラスターに参加できる
• kubectl get nodes 参加しているノードを調べる
• kubectl create deployment imageからpodを立ち上げる

yaml

• kind: ServiceAccount service Accountをつくる
• kind: ClusterRoleBinding ServiceAccountを紐づけできる

Start containers using Kubectl

command

• kubectl describe 対象の詳細を表示できる
• kubectl expose ポートをexternal-ipに紐付けるやり方。実際はserviceを作成する。
• kubectl scale --replica=3 deployment * のpod数を上げる

kubectl get svc svc = services

エンジニアがエンジニアであるために

はじめに

久々に思い立ってブログを書くことにしました。
僕が思う「エンジニアがエンジニアであるために」について、まとめようと思ったからです。
ここで言うエンジニアは俗に言うWeb業界がメインです。（僕がそうなので）
本とかブログとかを交え紹介をしていこうと思います。
基本的に３つの軸で書いていきます

• 考え方を身に付け
• 良いとは何かを知る
• 自分の知識を更新していくこと

この３つが必要だと、僕は思います。個人的見解なので、ほかにももっとこういう考え方あるよ、とかもあると思いますので、参考までに読んでいただけるとうれしいです。

考え方を身に付け

考え方を意識すること

まず、エンジニアであるということは、柔軟な思考と戦略的な思考が必要だと思います。そもそも今目の前にある課題をクリアするために、コードを書くだけが解決の方法ではありません。オープンソースを利用して対応する方法もあります。DBも多種多様です。柔軟に考えプロダクトを前進させていかなければいけません。

最初にお勧めしたいのが、このストラテジックマインドです。
企業経営のための本と書いてありますが、本質は戦略的な思考の本です。エンジニアは常に考えなければいけません、課題をどう解決するか、将来どのようにプロダクトを成長させるのか。その中で、いろいろな自分の固定概念やあるべき論に縛られることがあります。その時にどう考えればいいかを紐解く一冊になると思います。
books.rakuten.co.jp

次にお勧めしたいのがエッセンシャル思考です。
これは有名な本ですね。まず、エンジニアは時間がないことを知らなければいけないと思います。自分が勉強できる・成長できる時間。仕事中の時間をなにに使い、何に貢献するのか。なにも考えないとすぐに１年終わってしまいます。エンジニアには時間がないのです。そのため、「しないことはしない」、「やるべきこと」、「やりたいこと」をするためにどういう考えを持つ必要があるか。正直これができてないエンジニアは、成長が鈍化するだけでなく、ストレスをためてしまうかと思います。
簡単に読める割には、多くの発見がある本です。
books.rakuten.co.jp

エンジニアには文化があることを知ること

エンジニアリングをしていると、当然のように人とかかわることがあると思います。直接でなくてもコードの中やシステムを通して間接的にも多々かかわることもあると思います。開発をする、チームを作るということは、そのメンバーで文化を構築していくということを意識することが非常に重要だと思います。AgileやScrumなどもその文化の中のひとつだと思います。文化はリーダーだけでなく、そこにいるメンバー一人ひとりによって代わるものです。

文化については、ここら辺がお勧めです。どういう組織を作りたいかGeekな集団とは何か。
books.rakuten.co.jp
Spotifyの文化は、すごく参考になります。英語ですがスライドを見ればなんとなくわかるかと思います。
labs.spotify.com
labs.spotify.com

ちなみに、僕は文化として、重要だと思ってることは大きく３つ合ります。

• 真剣に振り返るできること
  • Retrospective や Postmortem : https://landing.google.com/sre/book/chapters/postmortem-culture.html
• 安心感があること・失敗を恐れないこと
  • Spotifyの文化だとFailure Celebration: 失敗をして新たな発見をできたことを祝う。
• 先を見越し動くこと(プロアクティブ)
  • 言われて実装するのではなく、先見の目を持って技術投資を行い、プロダクトを改新していく感じ
  • フォードもこの文化を持ってる１社ではないかと思います。

「もし顧客に、彼らの望むものを聞いていたら、彼らは「もっと速い馬が欲しい」と答えていただろう。」
by ヘンリー・フォード（アメリカの自動車会社「フォード」の創業者）
http://meigensyu.seesaa.net/article/205528783.html

良いとは何かを知る

良いコードを知ること・良いアーキテクトを知ること

コードを書くときに、動けばいいや？って書いてるとそれは大間違いです。コードを書いた瞬間からそのコードの運用が始まります。コードを運用するためにはコードを読まなければいけません。そのためには、どのようなコードが読みやすいのか知る必要があります。僕はこう考えています。「企業の成長速度は、コードの良し悪しで決まる」と。改修しやすい、変更しやすいコードは企業のビジネスの変更に強く、その仮説検証を促進してくれます。逆にテストがなかったり、汚いコードはすぐにリリースはできますが、変更に弱く、いざビジネスを進化させようとする際に足を引っ張ります。
ゆっくり読んでも１週間くらいで読める本だと思いますので、とりあえず読むといいと思います。
books.rakuten.co.jp

次にお勧めしたいのが、レガシーソフトウェア改善ガイド
これを読めば、そもそもどんなソフトウェアが危険なのかの勘所とそれに対してどうすればよいかがわかります。なので、自分がレガシーソフトウェアに携わってないと思っていても、１度読むことをお勧めします。そもそもソフトウェアの構造がここ数年でどのように変わってきたかもわかるので、ある意味歴史の教科書です。個人的に、心に残ってるフェーズは「チームが既存のコードを改修しなくなったらそれはレガシーの始まりである。」という、組織文化についても少し触れていた点です。
books.rakuten.co.jp

使っているモノをちゃんと知ること

自分の扱ってるプロダクトに合わせて言語習得をしたりすると思います。既存のコードや書きたいコードを検索して調べて、それで実装して、リリースしたりしてると思います。でも、本当にその言語の強み、フレームワークの利用方法を学習してますか？なんとなく使えるからと、怠らずちゃんとそれがなんなのか知りましょう。先人たちが知るべきことを示してくれてます。

• Scalaだと
  • Scala School
  • Introduction · Scala研修テキスト

ベストプラクティスを読む

あと、ツールやDBだとベストプラクティスは結構公式に乗ってます。きちんと理解しましょう。
Googleで「Ansible BestPractice」とか打つと大抵出てきます。独自の発想で使うのではなく、ベストプラクティスに合わせて使いましょう。
そもそも、ベストプラクティスはツールの意義に沿って案じてあります。それに沿わないと、ツールがバージョンアップするときに取り残されて将来古いバージョンを利用し続けなくならなければいけない危険性があります。そんな、運用したくないですよね。

• Ansibleだと
  • Best Practices — Ansible Documentation

• Jenkinsだと
  • Jenkins Best Practices - Jenkins - Jenkins Wiki

自分の知識を更新していくこと

幅広くアンテナを持ち続ける。

ご存知のとおり、Web含めIT業界の技術というものは日進月歩です。
日々とまでは言いませんが、常に少しだけでも読むようにしておきましょう。課題を解決するときに新しいOSSのことを知っていたり、既存のOSSをバージョンアップすることでより、より便利にしたりと、プロダクトとあなたをアップデートしてくれます。
ここでは僕が日々キャッチアップしている軸とサイトを少しだけ紹介します。自分に合ったものをちゃんと見つけましょう。

幅広くキャッチアップする

いろいろなものはどこかでつながってるもので、浅くてもいいので幅広く知っておきたいものです。
hacker news
ここでは非常に幅広いジャンルの記事を読むことができます。
OSSだけでなく、世の中の情勢記事（技術によってる）などを読むことができます。TOP３０くらいが常にトップページに出てるので、朝から面白そうな記事だけ２，３個だけピックアップして読みます。
使い方的には技術新聞をぺらぺら読んで、情勢を知ったり、キャッチアップのために使います。
Hacker News

技術方法論を日々更新する

自分が良いと思っているやり方だけにこだわらず、いろいろな手法を勉強し続けることが大事だと思います。
dev to
表示速度が異常に早いことで有名になったページです。基本的にはWeb技術や手法についての記事が多いです。
自分のプログラミングや技術手法を改善するために、暇なときに読みます。
The DEV Community

利用してるものの知識を更新する

自分が使う技術回りは常にアップデートしておきましょう。それがそのまま自分の更なる強みになります。
ScalaTimes
名前から予測できるとおり、Scala周りの技術周り、ブログ周りを集めてるサイトです。
http://scalatimes.com/

ほかの言語でもいろいろとあると思います。メールを購読するようなサービスも意外と便利です。

• Ruby - https://rubyweekly.com/
• Java - http://javaroad.jp/news/index.jsp https://www.javaworld.com/news/

同ジャンルの競合を知る。

自分が利用している技術の同ジャンル等はできるだけキャッチアップできることが大事です。
DB-Engines
DBのランキング紹介サイト。各ジャンルごとにDBのRankingを紹介しています。
僕は、上位のものを使うというより、そのジャンルで今どういうDBが出てるのかを知るために利用しています。それで、自分の利用用途に一番合うのはどれかを考えます。やはり、何かを採用する際は、ちゃんと競合には何が存在するのかを知っておく必要があると思います。
DB-Engines Ranking - popularity ranking of database management systems

最後に

最近、どのようにすれば自分がエンジニアとして価値を出せるのかを考えることが良くあります。この記事は、それに紐付いて思ったことを書きました。こういった人材を育て、同じチームでプロダクトに向かっていけるといいなと思います。もちろん自分もこういったエンジニアで在り続けないといけないなと思います。

最近、リモートワークで使ってるツール紹介

リモートワークで利用しているオンラインツールを簡単に説明したいと思います。
個人的には必須のサービスになりつつあります。
ぜひぜひ、利用してみてください。

appear.in

appear.in – one click video conversations

簡単にテレビ会議をするためのサービスです。真ん中のリンクに適当な文字列を入力すると、会議が始まります。そして、そのリンクを会議したい人に渡すだけで、テレビ会議が始まるというすぐれもの。必要な環境はブラウザだけなので、なにか特殊なアプリをインストール必要が無いのがすごい楽。
画面はこんな感じ。

• ウェブでテレビ会議出来る
• 画面シェアが可能
• ページのリンクをコピペでほかの人にテレビ会議のページを教えることが出来る
• キック可能
• ページのロック可能(新規ユーザを限る感じ？)
• 超簡単

web white board

A web whiteboard

これは、ウェブ上にみんなで落書き可能なホワイトボードを作成するサービスです。
リモートで説明するときに、落書きしながら話したいときに、効果を発揮します。でも、マウスでのお絵かきはやっぱり難しいです。
ちなみに、この左下の人を＋するみたいなアイコンをクリックしたあと、"Invite to board"すると、シェア用のリンクが出てきます。

• オンラインで参加者全員でお絵かきするホワイトボード
• 文字も打てる、ペンのサイズ、色も変更可能
• 図も挿入できる
• 何気にチャットも可能
• 書いたホワイトボードを、imageにして保存可能
• 有料会員になると、ボイスチャット、ボードの保存が可能
• やっぱり、書きながら説明するのは良い。

idea board

www.ideaboardz.com

オンラインで付箋を貼り付けるスペースを提供してくれるサービス。
ブレインストーミングや、レトロスペクティブに使える。
こんなかんじで、スペースが提供される
　
各チケットにイイねできる

• オンラインでチケットを貼り付けるスペースを作るサービス
• 軸の数とその名前は自分で設定可能
• イイねボタンを利用して投票することができる
• 左上のボックスに文字を入れると、フィルタリングも可能
• 右上のリストからソート順も変更できる(作成順、イイね順)
• PDFやExcelとして出力可能
• ios/androidアプリもあるみたい
• リモートでも、レトロスペクティブしようぜ

まとめ

今感じで、最近リモートワークをしております。
今は、何かツールを探すときは、オンラインほげほげで検索するとたいてい出てくるので、それを吟味しながら使っている感じです。プランニングポーカーなどもあります。しかし、簡単に使えるものでないとすぐにめんどくさくなるので、そこらへんはツールを選ぶ上で注意が必要です。あと、いかに優れたツールがあれど必要なのは、リモート先の相手との信頼関係です。そこを築くことがリモートワークで一番重要な気がします。