YUTAKI.JP

Webエンジニアの雑談ブログ

タスク管理ツールについて

最近いろんなことをやっているのでタスクの種類が多岐にわたってきました。

プロジェクト

エンジニアリングマネジメント業務

1 on 1
個別進行案件の進捗管理
事務作業など

プロジェクトマネジメント

顧客との打ち合わせ
定例会参加
イシュー管理
計画
チームマネジメント

手を動かす系

プログラミング
インフラ作業、レガシー案件の設計保守拡張など

その他

社内行事への参加

ツール

使っているツールも大量にあります。

・chatworwk (顧客とのコミュニケーションに利用)
・slack (顧客アカウント、社内アカウント)
・yammer(社内全体連絡)
・backlog(顧客アカウント、社内アカウント)
・Trello(社内のチームのタスク管理)
・メール

こんな感じなんで、タスクを一括管理ができない状態になりつつありました。

これはだめかも、と思ったんですが
Todoistを入れてみたら、あっさり無理なく管理ができるようになりました。
色々タスク管理ツールは試してきたんですが自分だけのタスク管理はこのツールが一番馴染みました。

ざっくりした運用方法

タイトル

あんまりフォーマットにこだわらず自由に入れる。自分がわかればよい。
リンクとかその他、あとで探すのが面倒くさそうな情報はコメントで書き出しておく。

プロジェクトは、活動中のプロジェクトで切る。

OKRとか、文化創造とか、社内ルーチンとか、案件名とか

ラベルは、そのタスクをやるときのロールで切る。

事務作業 / プログラミング / インフラ作業 / PM / EM ... etc

優先度

その日に絶対やらなきゃいけないやつを赤にする。
できればすばらしい、というやつをオレンジにする。
できたらやる。というやつを青にする。
基本的にほとんどのタスクに優先度を設定します。

期限

基本的に入れる。
(適当であってもリマインドになるので、気にしなきゃいけないかどうかが日を跨いでも実感できる)
期限がきたらただズラすだけで、赤とかオレンジがよくズレていると自分の健全性評価が低いことがわかる。

なぜTodoistが馴染むのか?

たぶん、自分が持っているロールが多すぎる(兼任しまくってる)からなんだと思っています。
全部をやっていくことが最初から無理で、基本はいろんなものをリスケしまくることになるので
「その日に注力しなきゃいけないことは何か」がハッキリ見えている状態かつ
「リマインドしなきゃいけないやつは」将来必ず出現し
「できなかったやつはさっとリスケ」ができることが重要だからなんだと思います。

自分の役割が少ないならばTrelloとかのほうがいいのかもしれません。

あと、こういうやることリスト以外に
雑多なメモを蓄積しまくるツールの馴染むものを探しています。
(議事をとることが多いので本当に必要になる場面が多い)

Evernote
Boostnote
Notion

あたりを比べて使ってみているところです。

エンジニアリングマネージャに就任しました。

年始から一瞬で1月末になったような気持ちです。

ところで、今年から正式にエンジニアリングマネージャに就任しました。

エンジニアリングマネージャについて

エンジニアリングマネージャーは技術系管理職で
エンジニアのチームの生産性を最大化するために頑張る役職です。

組織によって最適な守備範囲は異なり、諸説あるのですが
使命は大きく分けると3つ

  • 良い環境、良い文化の形成支援を行っていく
  • 良い評価制度を作っていく
  • 良い採用活動を行なっていく

あたりと思っています。

そして、日々の鍛錬として

  • 技術的な学習は今まで通りかそれ以上に行なっていく
  • 組織作りに関する体系的な知見を広げていく
  • チームメンバーへより興味を増して、才能を発揮してもらえるように行動していく
  • そのための時間をより確保する

ということを継続していくことになると思います。

マネジメントについて

マネージャという仕事は高い理解力や言語化能力が要求されると思ってはいますが
こういったもの以上に、道徳や柔軟性、ストレス耐性、勇気、利他的な精神など
成果を出す上で人間そのものをかなり試されるものだと感じています。

自分は、わりと最近までは自身の成果を出すことに関心があるタチだったので
どちらかというとプレイングマネージャ的な要素が強いと自覚していました。

しかしここしばらくで仕事を通じて
よい技術者との出会いや、よいチームのプロジェクトマネジメントをする機会に恵まれ
チームが健全に活動することで出る成果の計り知れない大きさを実感することができ
少しずつではありますが、利他的な精神が培われているような感覚があります。

これからもしっかり貢献していきたいと思います。

2018年総括

あっという間に仕事納めになりました。
今年は本当に新しいことやタイトなことが様々あり、鍛えられた、大きな変化が得られた一年だったと思います。
来年はより使命感を持って自分のできること、自分だからこそできることを洗練させていきたいと思います。

今年やりたかったこと

パフォーマンスの発揮

×。得意なことに注力できていない。負荷もストレッチ気味

興味のある分野の勉強

○。色々な巡り合わせがあり、できた。

来年やりたいこと

パフォーマンスの発揮

本気で取り組んでいきたい。

興味のある分野の勉強

自分の立場に必要な勉強をしたい。そして成果を出して経験を積んでいきたい。

技術的な勉強を両立したい。やはりコードは書きたい。

業界コミュニケーション

業界でのコミュニケーションをより活性化させたい。

2019年は新しいスタートの年になると思っています。がんばろう!

インフラの進歩すごいですね

最近、kubernetes(コンテナオーケストレーションシステム)の勉強をしているのですが
インフラの世界の進歩を改めてすごいなーと思っています。
自分が見てきた変化をざっくりまとめてみました。

サーバマシン組み立てて頑張る時代

オフィスにサーバマシン。これに一通りのミドルウェアを乗せて頑張っていた。

f:id:yast03:20181203182552j:plain

トラフィックやばい。台数増やさなきゃ時代

分散しなきゃやってられなくなって台数が増える。
メンテ超きつい。監視も頑張らないと。。。

f:id:yast03:20181203182556j:plain

マシンは複数台が当たり前だ。ラックにしよ時代

もはやサーバというものは積み上げるもの。
ラックマウントにして監視ツールとかも準備。
NASストレージ等も導入されるようになった。

f:id:yast03:20181203182614j:plain

オフィスじゃ管理しきれん。データセンター構えよう時代

時期的には上記ラックと同じ頃ですね。
膨大なマシンを運用する電力、セキュリティなど
諸々考えることを減らすためにデータセンターを借りて
物理的なケアはプロに任せることに。

f:id:yast03:20181203182634j:plain

なんかもうクラウドでええわ。サーバはVMに。IaaS時代

マシンを自分で抱える時代は終わった。
VMを上手に制御してくれるプロバイダに委任するように。

f:id:yast03:20181203182638j:plain

もはやサーバはコンテナに。スケーリングも自在。コンテナオーケストレーション時代

Cloud Native!
Immutable Infrastructure !
Immutable Deployments !

サーバを作ったり壊したりはもはやプロセスレベルに。サーバごとデプロイできたりするようになってきた。
(この辺まで到達している現場はリテラシーが高いと感じます)

f:id:yast03:20181203182643p:plain

(そろそろ)もうアプリのことに集中すればよろしやん。サーバレス時代

アプリの要件に応じてコードレベルで調整できる時代に(なりつつある?)
サーバーは必要なものが自動選択されるように。
(業界のえらい人はこの辺をかなり意識しているようです)

f:id:yast03:20181203182647j:plain

以上

時代の進歩は本当にすごいですね。
リソースの概念が複雑化していくこの先、よりシステムをオブジェクティブに捉えるスキルと
ビジネスで開発をするなら、コストの把握方法などをしっかり学んでいく必要があると感じました。
がんばろう。

マイクロサービスアーキテクチャ 用語メモ - 2

前回に引き続き、用語集です。
なかなか難しい単語も多かったです。

継続的インテグレーション

通称CI。ソフトウェア開発における習慣の名前。
エクストリーム・プログラミングのプラクティスの一つ。

プロジェクトメンバーがそれぞれ開発した結果を頻繁に結合して
定期的にビルドやテストを行うこと。
それによって、問題に早期に気づくことができる。
散々それぞれ作り尽くして、いざ結合してみたらいろんなバグや調整が必要になった
なんてことが起こらなくなる。

頻繁にビルドやテストを行うことになるので
できるだけ処理を自動化しようとしたくなる。そこで出てくるのがCIツール。
JenkinsとかCircleCIとか。

マイクロサービスだと相互の影響確認とかをする上で
全体でCIしないと大変そうだな、という印象で、なるほどーと思いました。

コンシューマ

消費者、需要者、購入者、などの意味を持つ英単語
業務用・企業向けと対比して消費者向け みたいな使い方をされる

マイクロサービスにおいて使う側と使われる側とかでよく出てくる気がします。

ビジネスロジック

業務ソフトウェアの中で、具体的な業務で扱う様々なエンティティ(実体)
たとえば担当者、商品、顧客、在庫などを表現し、
また、それらの関係や処理の方法、業務の流れなどをプログラムコードとして実装した部分。
アプリケーション固有の処理やルールを記述したもの。
フレームワークなどの記述以外はほぼ全部ビジネスロジックか?

サブスクライバ

通知メッセージを受け取るユーザ(この場合はサービスか)

パブリッシュ/サブスクライブ

イベントを発行する -> パブリッシュ
それを購読する -> サブスクライブ
みたいな捉え方で外れないんじゃないかと思ってます。

リモートプロシージャコール

RPC。
ローカルで呼び出しをして別のリモートサーバで実行をする。
ローカルで関数呼び出ししていると見せかけて実は実行しているサーバはリモートであるとか。

実装上は意識しないで済むけど、どこでやっているかは隠蔽されるので
扱いかたを間違えると地獄という話が腑に落ちました。

ペイロード

伝送されるデータ全体のうち、伝送処理のための管理情報(ヘッダやメタデータなど)を除いたものにあたる

リクエスペイロード、という意味が超よくわかりました

整列化 マーシャリング

異なる2つのシステム間で、データを交換できるようにデータを操作する処理
違う言語同士の変換とか。
PHPの変数-> json に、みたいなイメージ?

非整列化 アンマーシャリング

上記の逆で、json -> PHPの変数に戻す みたいな話

ハイパーメディア

コンテンツに様々なデータ=テキスト/画像/動画/音声などのリンクが含まれる概念

ハイパーメディアコントロール、なるほどなるほどって感じ。

セマンティクス

「意味」「意味論」
非常に捉え方が難しい概念。
実装において「これが正しい」と判断するための基準。
シンタックスと対で利用されることが多い?
protected function を定義したとして
シンタックス的には誤字脱字はないから正しい、としても
そのメソッドがprotected ではなく public である / privateであるべき
といった判断がされる場合は、セマンティクス的にはダメ。みたいなイメージか。

セマンティックバージョニング

バージョンの付け方。
1.2.3というバージョンがあるとして
左から順番にメジャー、マイナー、パッチバージョンを表している。
APIの変更に互換性のない場合はメジャーバージョンを、
後方互換性があり機能性を追加した場合はマイナーバージョンを、
後方互換性を伴うバグ修正をした場合はパッチバージョンを上げる。


以上です。
マイクロサービスだと、やっぱりパブリッシュ / サブスクライブ
とか、セマンティクスとかの用語が体感に落ちていないと文脈がわかりづらいということがよくわかりました。
(多分、この概念がわかっていないとメッセージブローカーとか言われてもハァ!?ってなる)

だいたい読めるようになってきたので
次は続かないかもしれません。

マイクロサービスアーキテクチャ 用語メモ - 1

https://www.amazon.co.jp/dp/4873117607/ref=cm_sw_r_tw_dp_U_x_VhHRBb8BENJZCwww.amazon.co.jp


最近お勉強でこの本「マイクロサービスアーキテクチャ」を読んでいるのですが
横文字になかなかついていけなくて、evernoteにメモって一つ一つググりながら進めています。
今回はそのメモの一部を紹介します。

これらは、何言ってるのかサッパリわからないところから
ざっくりイメージを捉えるためにさっさとググってメモったものなので、間違っているかもしれません・・・

モノリス / モノリシック

一枚岩

コンウェイの法則

組織構造と設計は似てきちゃう。グダグダな組織構造だと設計もグダグダになりがち。
最適な設計を目指すなら組織構造も最適に。
(ここもっと理解したい)

チェックインをリリース候補として~

チェックイン = 要するにチェックアウトの逆、VCSに反映する内容。

コンシューマを変更することなく~

需要者 購入者 消費者 を変更することなく

レジリエンス

回復性 復元力 弾力性
不整合とかに強いってことか?

オンデマンドプロビジョニングシステム

リソースの調達を一括でやってくれるやつ AWS的な

サービスのセマンティクス

利用されている要素が正しく動作するかを判断する基準

フレーミング

枠づけ

メトリック

相手のところまでたどり着くのにどれだけ大変か (測量とかが語源)

エンドポイントのバージョニング

端末 拠点のバージョニング

サーキットブレイカ

良くない事象(つまり障害)が頻発すると「あ、これはやばいから一旦この導線をオフにしていこう」
という仕組み?

コードを介したガバナンス

コードを介した統治 / 支配

サイドカーサービス

親サービスと同じライフサイクルを共有し、親サービスと共に作成され、終了するサービス
アプリケーションのコンポーネントを別のプロセスまたはコンテナーにデプロイして
分離性とカプセル化を実現

デリバリチーム

作るチーム?

ドメインモデル貧血症

振る舞いとデータが分かれてしまっており、手続型の設計・実装になってしまう状態。
(ここもっと理解したい)

スタブ化

外部プログラムとの細かなインターフェース制御を引き受けるプログラム。



次回、続くかもしれません。

Macの.DS_Store、リソースフォーク(._で始まるファイル)を削除するオリジナルシェルコマンド

Macで共有フォルダをマウントして開発をしていると

.DS_Store
._ ファイル

が邪魔だなーと思うことがよくあります。

DS_Storeに関しては、あらかじめ作成しない方法があります。
下記でまとめてくださっている方がいらっしゃるので紹介
.DS_Storeの仕組みと削除&作成しないよう設定する方法 | UX MILK


でも、リソースフォーク(._ファイル)はFinderでマウントしているとどうしても作られてしまうことがあって、邪魔です。

そこで「rmrcforks (rm resource forksの略)」というコマンド一発で
current directory以下に存在する._ ファイルと .DS_Storeファイルを削除できるようにしてみました。

設定

# .bash_profile でパスが通っていること
PATH=$PATH:$HOME/bin
#!/bin/bash
# ~/bin/rmrcforks (755で作成)

OPT=${1:-0}

if [ ${OPT} = "-t" ] ; then
    find ./ \( -name ".DS_Store" -or -name "._*" \)
else
    find ./ \( -name ".DS_Store" -or -name "._*" \) -print -exec rm {} ";"
fi

実行

# 実際に消す
$ rmrcforks
# リストアップだけして消さない
$ rmrcforks -t