分人

 さいきん興味のわく本を教えてもらう機会があってそれを読んでみた。平野敬一郎の”私とは何か――「個人」から「分人」へ”というタイトルで、分人という概念で個人を捉えることを提起していた。そんな「分人」そのものについては書かず、これまでぼくが読んだもの、知ったものとリンクしていた気がするので並べておく。


荒野のおおかみ - ヘッセ
"胸や体はいつだって一つだが、その中に宿っている魂は二つ、あるいは五つでなく、無数である"
 以前に友達の前で一貫性を欠いたことを言ったときに、これを言ってごまかしたことがある。そいつはヘッセが好きだったから納得してくれた。
 この書き方だと「相手によって」という条件に限らず、時と場合によって表に出てくる魂が変わることもあるのかとも思うが、それでも「個人」というのが一つの特徴のみを持つという考えには反している。


ブリタニカ百科事典
"性格とは、気分、態度、意見、対人的態度を含む思考と感情と行動の癖で、遺伝や学習の結果である。性格とは個人差のことであり、環境や社会に対する関係を観察すると把握できる"


ラルフ・ウォルドー・エマソン
"他人とは、自分自身の心を読み取ることのできるレンズである"


アンドレ・ジイド全集〈第14巻〉 - アンドレ・ジイド
"これに対して、ドストエフスキーはわれわれに何を示しているのでしょうか。自分ら自身に対して一貫した関係を保つということをなんら意に介さずに、自分らの固有の性質が受容しうるあらゆる矛盾、あらゆる否定に喜んで降伏する人物たちをです"


オルテガ―人と思想 - 渡辺 修
"ある物の実在は 、それが見られる視点がどこにあるかとは無関係に、それ自体が独自にそこにあるのだ、とする考え方が昔からあったが、それは誤りだとオルテガは断定する。実在は風景のように、すべてが同等に真実で同等に無限のパースペクティブである。唯一無二であると称するようなものが、虚偽のパースペクティブである"


異邦人 - カミュ
 この物語の主人公ムルソーは、殺人による裁判にかけられ死刑となった。ムルソーは人の死を悲しまない残忍な人物として一貫性を押し付けられた。
 ”私とは何か――「個人」から「分人」へ”では下記のような文があって、読みながら裁判で人格を押し付けられていくムルソーを思い出した。
”社会としては、できるだけ不確定要素を取り除きたい。個人が首尾一貫していなければ、社会の基本となる構成要素が不安定になり、方々で機能障害が起きてしまう”
comment: 0

2018: ゆく年くる年

 一年が終わるので今年にあったことをまとめておく。まあ自分のOSSのメンテを継続しつつ、勉強しつつ、転職したりといったところか。

--- OSS
Piexif
 Pythonでexifの編集をできるライブラリ。今年はGoogle CloudのプロダクトマネージャからIssuesが上がってきたり、AWSのあるリポジトリで使用され始めたり。
 機能としてはPNGもexifをメタデータの形式としてサポートという話が出てきたので実装を進めたが、テストに使えるPNGがなくてテストをまだ書いていない。なのでマージはまだ。

piexifjs
 ↑のものをJSに移植したもの。だいぶ前に書き上げたものだったのでソースが一つのファイルで可読性悪かった。仕事でTypeScriptを使ったので、それで得た知識をプライベートプロジェクトに輸入させてもらった。あとはRollup使ったりでかなりモダンな構成にできた。そのあたりの改修が現在ベータバージョン。

 仕事やプライベートでの技術調査をしていると、OSSに費やす時間をひねり出すのがだいぶ難しくなってしまっている。この辺はだいぶ割り切った考えをするようになった。金を取っていなので、最大限のサポートはしなくていいという考え。

 Issuesは具体的、再現可能な報告が来ない限り積極的な対応を控えるようになった。
 重大なバグがあればもちろんできる限りすぐ対応する。しかしIssuesには、それじゃ再現できんやんという情報量で上がってくるものが少なくない。ヒアリングでデバッグできるように情報を聞き出すまで3、4日費やしたりする。しんどい。なので再現可能な情報が来ない限りは積極的な対応はしないで待つ。OSSなのでプルリクを期待して待っている。

--- 仕事
 今年は転職した。職種はプログラマ(あるいはエンジニア)のまま。待遇的にも技術的にもいろいろ良くなった。

 年収が100万円以上200万円未満でアップ。有休がチャットでのメンバへの通知とシステムでの日付指定で取得できる。フレックス。こういうところで守るべきものが守られていて、その上でこっちを信用してくれてある程度の柔軟さを与えてもらえるとがんばっていかねばという気分になる。
 転職後、仕事で学んだ知識をプライベートプロジェクトに活用したというのも、前職にいたときには考えられなかった。前職で使う技術は枯れたもの、あるいはそれを通り越したものばかりだったと思う。それではまずいと思いいくらか変えようとしたが、結局なにも変えられなかった。

 転職活動では会社でなにをしたかを話すのがスタンダードなところだろう。だけどそこで技術的にアピールできるところはかなり少なかったので、プライベートプロジェクトにつっこんだ技術の話をしながら、「会社でこういうことをしていきたい」と話した。

--- 技術
 このブログを動かしているコンテナホスティングサービスがあと一か月もしないうちにクローズという通知が来た。AKSを始めたのでそっちに移植。
 仕事で課題が見えているので、自分のOSSのメンテはほどほどに勉強していきたい。今年はk8sをちょっと触った程度だったのでそこはがっつり。



 今年は定年説のある35歳を目前に転職した。ロールはほぼ変わらないが、周りの開発者からいろいろ学べる環境になった。いい環境になったので邁進していきたい。
comment: 0

YahooTechConferenceのメモ

 YahooTechConferenceのメモ。少し時間がたってしまったけど。
 内容としてはk8sをサービス化というのが、やっぱりDockerを追っている身として面白かった。Dockerがk8sを取り込んだが、そうなる前、すでに三年ぐらい前からk8sをサービス化するものを開発していたとのこと。というのを考えると、バックエンドやらフロントエンドやらどこかはわからんけど、すでにどこかで「次」が来ているんだなぁと思うなど。

Kotlinの導入と展望
==================
C 14:00-
 Kotlinはけっこうというかかなり短く簡潔に書ける。


なぜKotlinを入れるか
・desugar問題
・Swiftと似ている→iOSエンジニアと相互理解を深められる。実際深まった
・イベントハンドリング、通信、非同期処理が簡潔に書ける

Kotlinを入れるリスク
・学習コスト
・ビルド時間が増加しない?
・既存のCIパイプラインが継続して使えるか

Kotlin in Actionは学び初めによさげ

実際に導入するルール
・単純にKotlin置き換えをするタスクは積まない

一日かけてチームでToDoアプリを作って勉強(ToDoなのはDBキャッシュや非同期処理などいい教材になるから。それで十分にそれ以降の開発をキックできた)

ペアプロで

Kotlin導入結果
・導入直後からメンバーがKotlinに好感触
・Swiftコードも読めるようになった
・CIパイプラインはそのまま動いた
・サーバサイドKotlinへの流れが生まれた(Springが使える)

技術導入はトップダウンでやるのは危険。それぞれのプロジェクトで環境も要件も違うのだから、求めるものも違う。



PaaSな開発基盤
==============
A:15:00-
 最適化のためにPaaS化していきたい。
 CloudFoundry→PaaS
 Conなんとか→CI/CD

CloudFoundry→OSSのPaaSプラットフォーム
プライベートPaaSってことか

Coucourse→OSSのCI/CDプラットフォーム
CloudFoundryと連携が良好


アジャイルマニフェスト:継続的な価値の提供を提供したい、すべき
デリバリの時間を短くしていく
継続的デリバリは早さだけではなく安全性も達成させてくれる
複雑な問題は出来事から学んで対応する

半自律チーム
 理解の共有
 相互機能、バランス
 素早い判断
 ぶっといコミュニケーションバンドワイズ

昨日までの開発者
 仕様を読む
 コードを書く

明日の開発者
 聞く
 コミュニケーション
 テストを書く
 コードを書く
 デプロイ
 学ぶ
 Reflect

テストかけ、ユーザサーベイやれ、CI/CDやれ

実験的思考
 ちーむでいろいろ試す
 間違ってもいいんだという意識の共有
 →その後に間違いを防ぐ仕組みを作れたらとてもいい。とくに自動化とか人の手を介さない方法を導入するとかって方向で

カルチャーは実際みんなで働いている毎日というのが反映される

アプリケーションの高速デプロイを可能にする技術(k8s)
===================================================
C:16:30-

社内向けにContainer as a Serviceな部署がある
コンテナ化のメリット
 ライブラリ、パッケージの依存関係がコンテナ単位
 パッケージング、デプロイも

k8s
 スケーリング、オートヒーリングが可能
 コンテナのデプロイ、スケーリング、管理

社内でKubernates as a Seriviceなるものがあって、管理が楽になっている

もともとVMの管理コスト増加があった
メンテとかで開発にリソースが割けなくなってきていた

まずはローカル環境から導入した

k8sのデータを入れているetcdというkvsがある。k8sをサービス化したかったらこれのバックアップとか考えなきゃいけない。
Yahoo
comment: 0

三本の進路

エンジニアとしての進歩の仕方を考えてみると、現在では三つの進路が目の前にある。

テストやデプロイの自動化によって質で貢献
→突き詰めていくとサイトリライアビリティエンジニアになると思う

UXを磨いてユーザを魅了して実績で貢献
→いまはフロントエンドエンジニアがその役割を担っている

データサイエンスで経営判断に貢献
→データサイエンティスト


 サーバを立てて、フレームワークを使っても使わなくてもとりあえず目に見えて動いて、テストにとおるものを作るのは当然のこと。それに加えて上に書いたような付加価値を、どれか一つでも選択して加えられるようにしていくのが取るべき道だと考えている。
 組織で言うなら、成熟したプロダクトでは上記三つの技能を個々に持つ技術者が集まって、チームでプロダクトをその先へ進歩させていくべきだと考えている。毛利元就の三矢の教え的な。それぞれ環境の進歩への追随や高度な専門性を要するため、フルスタックという言葉で全部を一人がやるのは非現実的だ。
 そのチームのマネジメントはどうあるべきか。三つの技能はそれぞれ高度な専門性を要する。そんなチームで上に立つタイプのマネジメントをやるとするなら、その高度な三つすべてをよく理解してなければならない。そんな超人ほぼおらん。となるとサーバントリーダーシップと呼ばれているやつでいくのがいいだろう。
マネジメントスタイルの違いがもたらす「圧倒的スピード感」の違いと「楽しさ」
comment: 0

ゆく年くる年

https://blog.hmatoba.net/Article/138


 今年の棚卸を10月に既にやっていて、その後にプロジェクトが炎上して私生活がほとんどなかった。なので10月以後の個人的進展が少ない。でもこのブログをコンテナ技術で運用するところまではできたのでまずまずな年だった。欲を出すならReactでちゃんとなにか一つ作りたかったが。
 来年はコンテナ技術をもっと試して学んでいきたい。コンテナ便利だなーからオーケストレーションも便利だなーと思っていたところに、Dockerがk8sをサポートするとの発表が来た。個々のコンテナ監視をしなきゃなーという状況になっていたので、k8sのポッドの概念などを読んで目的にフィットすると思った。面白そうだし便利そう。あとコンテナで運用しているアプリのログもいろんな運用例が出てきている。ここはまずアプリとして動かすことを優先してやってきたので後回しにしており、コンテナ運用の次の課題として残っている。
 あとひょんなことから一緒にプロジェクトをやれたすげー人に、UMLやっておくといいよと言われた。設計やるし、デザパタと一緒に抑えていきたい。

 来年は、
・コンテナ技術をさらに追っかけるし試す。k8sとログ
・まだ勉強中のReactを使えるようにする
・設計のためにUMLとデザパタ
というところは確実に抑えていきたい。

 しかしまあ大晦日にして、コード納めもせずに紅白を見ながらライブラリに新機能を追加している。やっぱりプログラミングは面白いもんだなと。
comment: 0