プラットフォームエンジニア1年目の2020年を振り返ります。大変だったこと、うれしかったこと、キャッチアップを加速させるためにやったことなど。

2020年

異動

2020年に、マイクロサービスを開発するためのプラットフォームを開発・運用するチームに移りました。

Software Engineer, Microservices Platform

2019年までは、そのプラットフォーム上で稼働するマイクロサービスを開発・運用していました。2018年9月の入社当初、GCP、Kubernetes、Goの業務経験がなかった状態で設計〜リリースまでを担う中で、プラットフォームが提供する機能に大いに助けられました。

一方で、サーバーレスなテクノロジーが好きだったり、Kubernetesを学ぶ中でKnativeに出会ったりしたことで「マイクロサービス開発者から見たプラットフォームの利便性」はもっと向上できるのではないかと思い、Microservices Platformチームに参加させてもらうことにしました。

1年目にやったこと

列挙するとつぎのようプロジェクト・役割に携わりました。

  • オンサポート(複数回)
  • Istioワークショップ
  • Network Policyの導入
  • Disaster recoveryテスト
  • リライアビリティ強化

6週間毎に、担当が変わります。

オンサポート

最初はオンサポート(とオンボーディング)でした。マイクロサービス開発者から寄せられるサポート依頼に対応します。オンボーディング観点では、アーキテクチャやリポジトリなどには馴染みがあったので、KubernetesクラスターやTerraform周りのオペレーションや、プラットフォームチームが開発・運用しているコンポーネントのキャッチアップが中心でした。

Terraformは何も知らなかったり、KubernetesのオペレーションはマイクロサービスのデバッグやCKADで出てくる範囲くらいしかわかりませんでした。そのため、

検証環境でやるのを見せてもらう -> 開発環境や本番環境でついてもらってやる

というペアオペレーションが多かったです。フィードバックも毎日夕方に1on1してもらって、改善の日々でした。

マイクロサービス開発時に自分もわからなくて頼っていたエラー対応が、チームを移ったからといって即座にわかるようになるわけがありません。間をおいて何度かオンサポートを担当したり、他のプロジェクトに取り組むなかで理解を深めました(今もなお。アサインに配慮を感じつつ)。

Istioワークショップ

Istioワークショップは、Istio何もわからんの状態からいろいろキャッチアップして、マイクロサービス開発者向けに「サービスメッシュとは何か」を話したり、マイクロサービスのテンプレートとなるマイクロサービスで実際にIstioの機能を試すハンズオンセッションです。

外出自粛直後の3月の開催だったので、慣れないながらもSlackでコミュニケーションしつつ、Google Meetでスライドやターミナルをシェアしながらがんばりました。マイクロサービス開発者目線では、どんな便利なプラットフォームの機能も、機能開発が忙しいときには導入やキャッチアップ自体がかなりのハードルです。こういう試みは大事と思いつつ取り組みました。

つぎの本、Udemyの講座、登壇が特に役立ちました。

ドキュメメントは読みますが、最初にDemoを含む動画で概要をつかむと捗りました。

Network Policy

Network Policyの導入は、KubernetesのNetwork PolicyをTerraformモジュールも利用しつつマイクロサービス開発者が利用できるようにするものです。

今回は利用しない機能、デフォルトで有効にすべきポリシー、サポートするユースケース、段階的な移行方法などを議論しながらDesign Docを書きました。議論のスコープに、Network Policyに限らずプラットフォームコンポーネント全体に影響する事柄もあったことから、シュッと決めきれず難しさを感じました。しかし、ユーザーインターフェースとしてのTerraform variableや、設計議論の進め方など、学ぶことが多かったです。

また、導入にあたり希望マイクロサービスのベータテストを行い、フィードバックをもらって改善するプロセスなどは「プロダクトとしてのプラットフォーム」を強く感じました。

会社のテックブロクは書きませんでしたが、技術的にはつぎの記事のようなイメージです。

Terraform Kubernetes Providerとkindで試すNetworkPolicy

こういうユースケースのテストにこそTerratestを使ってみたかったです。最近出した本中のモジュールで、はじめて使いました。

Disaster Recoveryテスト

Disaster Recoveryテストは、GCPのTokyoリージョンが利用できない状態になったら…を想定して、すでに用意していたDisaster Recovery計画に基づきOsakaリージョンでサービスを一時的に立ち上げるものです。

クラスター内のリソースバックアップにVeleroを利用し、復旧用スクリプトを用意するなどしました。チーム横断的にとりくむプロジェクトだったので、あえて議論の枠を準備したり、定例や振り返りをリードしてみたりに挑戦しました。

リライアビリティ強化

リライアビリティ強化は、Datadogのモニター、ダッシュボードなどを見直たりしていい感じにアラート対応できるようにする取り組みです。

数百あるDatadogのモニターをすべてリストアップし、Playbookがないものを洗い出して追加したり、よくアラートが鳴るものの原因を調査したり、絶賛年末大掃除みたいな感じでした。

メンバーが増えて、再現可能な状態でオンコールにオンボーディングするには、適切な閾値でアクションのとれるアラートが鳴るのは大前提です。

その他

インターンメンバーの面接・メンターも担当しました。これまで、中途メンバーの面接やメンターはやったことはあったものの、インターン関連でははじめてです。

これがすべてです。

メンターという形ではなくても、プロジェクトのリードとして新しく入ってくる方のサポートをする機会もたくさんありました。学びの機会にあふれています。

キャッチアップとアウトプット

もちろん、業務中も必要なキャッチアップ時間やサポートはありました。しかし、僕は闘争する民族なので、これまでもやっていたプライベートOKRで四半期毎に身につけたいことを決めて取り組みました。キャッチアップすべきことは無限にあるので、「この四半期はこれ以外はやらない」をはっきりさせる意味合いが強いです。

OKRは、各記事でなぜそれが達成したいのかや、どの程度達成したのかなどの振り返りと合わせてまとめています。

2019年10〜12月の振り返りと2020年 〜YAML Engineerとしての闘争〜

2020年1〜3月ふりかえり 〜HCLエンジニアとしても闘争〜

2020年4〜6月ふりかえり 〜より抽象的なプラットフォーム仕草を身につける〜

2020年7〜9月ふりかえりと10〜12月OKR 〜プラットフォームエンジニア設計譚〜

2020年10〜12月ふりかえりと1〜3月OKR 〜旗を立て始める〜

資格

1年と少しで、KubernetesとGCP関連の試験をいくつか受け合格しました。

  • 2019/12: Certified Kubernetes Application Developer (CKAD)
  • 2020/3: Certified Kubernetes Administrator (CKA)
  • 2020/6: Google Certified Professional Cloud Architect
  • 2020/9: Google Certified Professional Cloud DevOps Engineer
  • 2021/1: Google Certified Professional Data Engineer

Kubernetes関連のものは、テストでも準備でも実技不可避だったので取り組みました。Kuberneteクラスターのバージョンアップなどでかなり役立ちました。

GCP関連のものは、それぞれ動機が異なります。Cloud Architectは、Terraformの本を書こうとしたらGCPの基礎理解がなさすぎて書けなかったからです。執筆を一時中断し、あわてて『Official Google Cloud Certified Professional Cloud Architect Study Guide 』を読みました。模試Webサービスつきなことや、物心ついてからクラウド概論に触れてなかったこともあったりで役立ちました。文章に品があって良いです。

Cloud DevOps Engineerは、SREの原理・原則を理解したかったタイミングで確認テストとして受けました。テキストは『サイトリライアビリティワークブック ―SREの実践方法』です。

Professional Data Engineerは、GCPのDBまわりをざっくり知りたかったのと、Terraform本にデータパイプラインの例を足したかったので勉強しました。安定の『Official Google Cloud Certified Professional Data Engineer Study Guide』が教材です。

極論資格として取得できてなくてもよかったですが、どの時期に何を勉強していたかがわかりやすくていいですね。

執筆

1年で3冊の本を執筆・改定しました。毎Q締切があってきつい1年でしたが、取り組んでよかったです。

Knative本は、同僚に「なぜIstio(VirtualService)を使わずにKnativeはトラフィックスプリッティングのような機能を実現できるのか」と質問されて答えられなかったのがきっかけで調べることにしました。ちょうどIstio関連のプロジェクトに取り組んでいたタイミングで、ネットワークまわりをいろいろ調べられました。

Terraform本は、GCPでTerraformを体系的に学ぶための情報がないという問題意識に基づき書きました。

特にオンサポートをやる上では、Terraformのデバッグは必須です。また、何かプラットフォームとして機能を提供する際には、Terraformモジュール設計が大体必要です。自分が実務に取り組む前に知っておきたかったことをまとめました。

さらに、マイクロサービスの開発者にとっても、有益な情報であると考えました。たとえプラットフォームがモジュールを提供しても、マイクロサービス独自に利用するリソースについては、現状Terraforを書かなくてはいけません。エラー調査をプラットフォームチームに依頼する際も、大まかな仕組みや原因がある程度わかった方が容易です。プラットフォームのエンジニアとしては、困ったら頼ってほしいと思いつつ、マイクロサービス開発者としては、頼っていいものなのか自分たちでなんとかできるものなのか切り分けできたかったという思いがありました。そういうものを意識しなくても、開発に集中できるプラットフォームを目指しているのは言うまでもありません。

(前年比)業務に密接に関連した執筆は「あ、これ昨日検証したやつや!」の連続で、本業に活きていている感がすごかったです。

ついでに、売上で椅子が得られたりしたのでとてもよかったです。

7〜9月のKRのひとつに掲げていたのが「学び方の改善」です。

学び続ける生き物は、その学び方を改善することで得られるメリットが計り知れないほど大きいです。

エンジニアの知的生産術 ―効率的に学び、整理し、アウトプットする』を読んだり、チームの人のおすすめリストを読んだりしながら自分なりに読書リストを作って進めています。意識的にOKRに関連させるようにしています。これら以外は読まないというわけでもないですが、読むのが速くないので特に大事なものに絞る必要があります。

Platform Engineerへの闘争🐸

読み終わった本。

こういうのも親身に相談に乗ってもらえるので、安心して闘争できるのがうれしいです。

複業

サーバーレスコミュニティのつながりもあり、複業にも取り組みました。以前いったんは始めたものの結局タイミングやフェーズ合わなかったり、執筆や寄稿もある意味複業とは思いますが、案件に入っていくのは初めてです。

いつか一緒になにかできたら…と思ってた方々と一緒に仕事できてよかったです。一方で、あまり案件に深く入れないまま終わってしまったので残念でした。SlackでGCPの質問に答える係を3ヶ月担当しました。

フロントと認証・認可まわりは課題っぽいです。

2021年

2021年のことも書こうとしたのですが、思ったより長くなったので別記事にします。

業務的には、引き続きPlatform Engineerへの闘争を進め、プラットフォームエンジニアとしての運用ももっと楽にできるようにしたり、マイクロサービス開発者向けにサーバーレスで想起されるような体験を提供していきたいです。

改訂2版 みんなのGo言語

全体の感想

ある程度自分でCLIやアプリケーション開発をした上で読むと、「あれってどうやると良いんだろう?ベストプラクティス的なのって何だろう?」という疑問が解決できそうな本でした。

僕は改訂前の本をA Tour of Goを一通りやり終えた後にすすめられて読んだのですが、あまりピンときませんでした。

しかし、プログラミング言語Goを読んで文法を理解した後に自分でCLIをいくつか書いてみたり、業務でGoのマイクロサービスをいくつか開発した今読むと実感できることが増え、改めて手を動かして確認したり、実践でも活用してみたいことが多いなぁと感じました。

全体的に各テーマ類似するパッケージの特徴や使い方やベンチマークを比較しながら評価・解説されていることが多く、自分で技術選定する際の参考にもなります。

Goを活用した開発を実践する上での課題を解決する手がかりが多く見つかるよい本でした。

各章の感想

1章 Goによるチーム開発のはじめ方とコードを書く上での心得

自分の開発環境を改めて見直すきっかけになってよかったです。

パッケージ分割の基準や大きいstruct作るべきではないのはなぜかなども言語化されていてなるほどなぁと思いました。

  • GOPATH、GOROOTは環境構築するたびに結局今ってどうするんやっけ?という気持ちになりますが自分の使い方では変える必要なさそうということでfix
  • Build ConstraintsをBuild Constraintsと呼ぶと意識して開発してなかったのでググる力が増しました
  • リポジトリ移動にpeco/peco
    を使ってなかったのでmotemen/ghqと合わせて使ってみます
  • Makefileのhelpコマンドは人が書いたワンライナーはっつけてましたがSongmu/make2helpよさそうですね
  • 「単独のパッケージとしてほかのプロジェクトから使えるかどうかがパッケージを分割する基準」よさそう
  • 「正規表現のパフォーマンスが悪いのは最悪ケースの処理時間が極端に遅くならないように設計されているため」知りませんでした
  • 「たくさんのフィールドを持つような巨大なstructを定義するのではなく、再利用可能な小さな部品を組み合わせてデータ構造を定義」よさそう

2章 マルチプラットフォームで動作する社内ツールのつくり方

一度でもCLIツールやアプリをクロスコンパイルして配布しようと思ったことがあるとありがたみが増す章でした。

バージョンアップデートを追うポイントについても学びがあり活かせそうです。

  • マルチプラットフォームに対応したツールを作るときは特にWindows周りでパス、文字列、ファイル操作、ホームディレクトリあたりを気をつけようと思いました。自分でCLIツール作るときはとりあえずmacOSで使えるものを作った後にクロスコンパイルしてWindowsとかでも使えるようにするぞ!みたいな流れだったので、最初から気をつけるべきポイントがわかっているといざ配布するときに体験を損なわずに済みます。
  • バイナリにリソースを埋め込むにあたり、jteeuwen/go-bindatajessevdk/go-assetsはもうメンテされないので、rakyll/statikgobuffalo/packrを勧めていた話の流れがよかったです。リソース埋め込みでまず思い浮かぶのがgo-bindataとgo-assetsだったので認識を改めることができました。
  • awesome-goGUIセクションがあることやGUI用のライブラリがたくさんあるのを知りませんでした。CLIツールを作るものという固定観念を打破してくれました。自分で積極的に作るモチベーションはないけれどそういう章があったら楽しめそうです。
  • 設定ファイルのフォーマットと場所をどうするかについて各フォーマット向けライブラリの成熟度などを比較した上で筆者の見解が述べられていたり、実装の注意点が整理されていたのがとてもよかったです。cgoを使っているかどうかによるクロスコンパイルの挙動差異や、ホームディレクトリ関連でcgoに依存しないAPIが特定Goバージョンから利用できるようになったことは自分がこれまで意識できていなかった観点で、バージョンアップを追うモチベーションやポイントの1つになりました。

3章 実用的なアプリケーションを作るために

タイムアウトやシグナルハンドリングなど、実践でよく使うが理解不十分だった部分の理解が深まった章でした。

  • 標準出力のバッファリングをあるLL言語と比較しつつ、bufioパッケージを利用した実装と利用していない実装を使ってシステムコール回数をstraceで観察していたのがよかったです。システムコール自体の重みがよくわかってないのでベンチとろうと思いました。
  • dustin/go-humanize便利そう。わかりやすく表示できるのも、わかりやすい形式で引数などに指定できるのもいいですね。
  • 乱数系のパッケージはおそるおそる使っている感があるのでmath/randcrypto/randの性質の違いがまとまっているのはとてもありがたかったです。
  • contextパッケージはタイムアウトやgoroutineを扱う上で必ず通るのでありがたかったです。シグナルハンドリングと合わせて載っていてありがたみが増しました。シグナルハンドリング実装はよく目にしますが、シグナルを受けたときのデフォルトの挙動がドキュメント化されているのは知らず、とても良い知見でした。
  • 「シグナルハンドリングでやるべき処理」
    • 外部からの新規リクエストを受けなくする
    • 受信時に実行中の処理が完了するまで待つ
    • メモリ上に確保したバッファをすべて書き出してファイルを閉じる

4章 コマンドラインツールを作る

CLIを書くときに実践すべきことが詰まっている章でした。

はじめてCLIを開発し、テストの仕方を調べるときも筆者のブログを読ませていただいた記憶があります。

flagパッケージへの気持ちも感じることができました。

  • パッケージ構成を考える上でバイナリ + ライブラリを提供するのか、ライブラリを提供するのかで変えるのは面白いなぁと思いました。ただ、バイナリメインでもコマンドはcmdの下において外部提供する意図の無いパッケージをinternal下に置くのもありなのかなぁとも思いました。何れにしても意図をパッケージ構成で伝えるというのは取り入れたいです。
  • flagパッケージの使いこなしを実装を追いながら学べ、その他サードパーティの利用方法や特徴と比較していた点がとてもよかったです。章全体でなぜ?が重視されていて学びが深まったので、筆者が標準のflagパッケージしか使わなくなった点も一層気になりました。
  • 「os.Exitはdefer文で呼び出した関数を実行せずに処理を終了する」あまり意識してなかった気がするので気をつけてみます。本章にも書いてあるとおりos.Exitは無闇に呼ぶべきではないと思っているので、仮に出会った時に見落としそう。
  • 「ロングオプション: 説明的、シェルスクリプトやドキュメント、ショートオプション: 簡単に素早く」そうだなぁと思いました。
  • 今度サブコマンドを扱うCLIを書くときはmitchellh/cliを使ってみようと思いましたがメンテされてない…?サブコマンドをインターフェースとして定義するの好きです。

5章 The Dark Arts Of Reflection

ベンチをとった解説がわかりやすく、reflectionのメリット・デメリットがよく伝わる章でした。

他の章でもベンチをとって比較するのは登場していたのですが、特に効果的に感じました。

  • 型アサーションとソートについてreflectパッケージを使う場合とそうでない場合のベンチを比較していて、利用場面を選んで使うべきという主張の説得力が増していてよかったです。
  • 動的にselect文を構築する部分は難しくてよくわかりませんでした。

6章 Goのテストに関するツールセット

アプリケーション開発で常に実践せざるを得ない感がもっとも強い章でした。

ベンチマークを普段ほとんどとってないので、実装方法で迷ったり、チューニングする上ではやらねばと思いました。

僕はモックはgolang/mockが好きで、比較はgoogle/go-cmpが気になるものの試せていません。

  • Exampleテストのfunction名でgodocのどこに載るかが変わるのを知りませんでした。
  • reflect.DeepEqualの挙動がtypeごとに説明されていてよかったです。ドキュメントにけっこう書いてあるんですね…!意外とオジェクトを比較するテストに出会っていません。
  • Race Detectorの出自を知らなかったので勉強になりました。使用時にメモリ使用量5〜10倍、実行時間2〜20倍になることや、静的解析ツール出ないことも書いてあってよかったです。
  • インテグレーションテストとユニットテストをBuild Constraintsで分ける話がよかったです。Makefileにテスト種別を区別して実行するためのパッケージ分類スクリプトが書いてあるのを見てきましたが、Build Constraintsを使うと明示的になりそうです。
  • カバレッジについては所属組織のデフォルトMakefileやIDE、ツール(Sourcegraph)に頼っていたのでそもそものgo toolの中身を知れてよかったです。

7章 データベースの扱い方

DBやそれを扱うためのORMの章ではありますが、ライブラリ選定をちゃんとやろうという気持ちになれる章でした。

普段GoのAPIを書くことが多く、フロントも込みで開発することがないので画面込みで開発する部分は別章が丸々設けられていても楽しそうでした。(それやると別タイトルの本になりそう)

  • cgoに対するpure goという概念を覚えました。
  • mattn/go-nulltypeの紹介が、DB文脈でnullableを扱う上での課題を十分に説明した上で出てきて良い流れだなぁと思いました。
  • ライブラリの選定プロセスを垣間見ることができる構成でとてもよかったです。
  • 「本書が古くなりこれらのライブラリが古くなってしまったとしても、プログラマのみなさんがやるべきことは変わりません。新しい技術要素を調査し、あらゆる候補を比較するためにベンチマークをとることです」は最高のしめでした。

改訂2版 みんなのGo言語

ちょっとやりたいことがあってDurable Functionsを調べているとき、そもそもAzure Functionsももくもく会でXamarinアプリからHttpTriggerちょこっと触ったくらいだったことを思い出し、さささっと把握したいなぁと思いました。

そんなとき目に飛び込んできたのがUdemyの1/12 17:00まで¥1,300セール(!)でした。

Udemyとは?

Udemyは、学びたい人、教えたい人のためのオンラインのマーケットプレイスです。プログラミング、マーケティング、データサイエンスなど、55000以上のコースを1500万人の受講生が学んでいます。

だそうです。



なんとなくAzure Functionsで検索してみたらそれっぽいのが出てきました。

Azure Functionsの講座の感想

とてもよかったですw

Getting Started with Azure Functions

ポータルで簡単なスクリプトを実行するに始まり最終的にはARMテンプレートでCIするまでを5時間で概観できるとは思っていませんでした。

標準的な開発を説明するだけでなく、複数ある開発手法(デバッグ、デプロイ)のメリット・デメリット比較やAzure Fucntions/Logic Apps/Microsoft Flowの使い分け、料金プランを比較したり、サーバーレス・マイクロサービスアーキテクチャのベストプラクティスをどう適用するかにまで話が及んでいて想像以上に本格的でした。

全部英語だったのでついていけるか不安でしたが、Udemy側で自動生成の英語字幕(Serverlessを一度も正確に表示できないなど不完全ではあるw)がついていたり、速度を変えれたり(*0.5、0.75、1.25、1.5、2)親切でした。

定価の¥15,000だったら尻込みしますが、これがたったの¥1,300だなんてラッキーだなぁと思います。

ちなみにお品書きはこんな感じでした。

1. Get Started with Azure Functions

  • The Course Overview: 2:25
  • What are Azure Functions?: 9:22
  • Setting Up Your Azure Account: 6:20
  • Writing Your First Azure Function: 7:38
  • How Does Pricing Work?: 9:08

2. Different Languages in Azure Functions

  • JavaScript in Azure Functions with NodeJS: 10:25
  • C# in Azure Functions: 10:45
  • F# in Azure Functions: 12:08
  • Python in Azure Functions: 10:41
  • PHP in Azure Functions: 9:46
  • Other Languages in Azure Functions: 4:27

3. Triggers and Bindings

  • Introduction to Triggers and Bindings: 7:33
  • Basic Triggers: 12:20
  • Storage Triggers: 13:50
  • Other Triggers and Bindings: 5:24
  • Advanced Bindings: 13:23

4. Architecting with Azure Functions

  • Choosing Between Flow, Logic Apps, Azure Functions, and WebJobs: 7:23
  • Choosing a Hosting Plan: 3:04
  • Best Practices for Azure Functions: 5:35
  • Security Concerns: 15:10

5. Building a Serverless Architecture

  • What is Serverless Architecture?: 6:38
  • Why Serverless?: 3:13
  • Serverless Considerations: 6:10
  • Serverless Best Practices: 5:03
  • Moving to a Serverless Architecture: 5:36

6. Testing and Monitoring Your Azure Functions

  • C# Integration Tests: 12:31
  • Using the Postman REST Client: 9:59
  • Monitoring Your Azure Functions: 11:55
  • Debugging Your Azure Functions: 6:35

7. Automating Deployment

  • Using Azure Functions Core Tools: 8:45
  • Using Git to Edit and Deploy Functions: 11:18
  • Introduction to Azure Resource Manager: 10:09
  • Using Azure Resource Manager with Function Apps: 12:16
  • Putting it All Together for Continuous Delivery: 9:18

Getting Started with Azure Functions

プログラミングの勉強に動画はあり?

どちらかと言うと無し派でした。

Code SchoolでRspecの勉強したときよくわからなくて若干トラウマです。

今回は

  • テーマ的に部分部分知っていた
  • 言語(C#)的に馴染みがあった
  • どういうポイントがあるのかを押さえたいという目的があった

ので、それらに適う形でかなりありだなぁと思いました。

ある程度知ってる前提で、実際の動作(ポータルからポチポチする、コードを書く)を1つ1つ見せてもらえるのはザザッとキャッチアップしたいときにはもってこいっぽいです。

Golang一瞬でキャッチアップ()しないといけないのでこれ(評判良い)を観てみるのと、他にもいいのがあったら買っておこうと思いました。

人にプレゼントもできるらしいです。

Go: The Complete Developer’s Guide (Golang)

英語動画コンテンツ

純粋にAzure Functions勉強したいという思いとは別にこの本を読んで思うところがありました。

(しつこい)

著者はプルーラルサイトでiOS、Android、.NETなどの講座を大量に持ってる人です。

資産形成の面で、たしかに1回作ればそれなりの期間は収入入り続けるのかとか、一瞬で古くなってしまうのではとか色々考えていました。

いざ観てみるとFunctionsの話はめちゃくちゃクオリティが高くて、これ1人でどうやって作んねん…って思ったら最後のページにCreditが出てきて9人がかりで作成されたコンテンツであることがわかって吹きました。

なかなかイバラな道なんでしょうか。

あとは今年の3月に1週間くらいアメリカに行って技術セッションに参加するので、Udemyにかぎらず慣らさねばって思いました。

独習C 新版のレビュー記事です。本の分量自体が索引含め606ページととても読み応えのあるものだったため、読んだ感想(ざっくり)からだんだん詳細が伝わるように書いていこうと思います。

全部読み、各章についているの理解を確認するための問題も一通り考えてみました。

こういう人が読むといいかも

普段業務や趣味でC#である程度意図通り動作するアプリケーションを書いているが…

  • 人のコードを読んでいて構文的にわからないことがある
  • 動くけどなんでそれが構文的に正しいかよくわかってないなぁと思うことがある
  • いつも手に馴染んだ書き方で書いているが、他にも書き方ありそうなので打ち手を増やしたい
  • C#を体系的に勉強したいけどなにを「体系的」とするか一例を見てみたい

書いたことがあるけど、動いている部分を説明できるように「基礎」を勉強し直したいときに読むとよさそうです。

僕自身が読むにあたっては理解や知識に漏れがる部分がどんどん埋まっていく感じがしました。

こんな人が読むのは厳しいかも・向いてないかも・書いてないかも

  • デスクトップアプリ、モバイルアプリ、Webアプリケーションのフレームワークの使い方が知りたい
  • Visual Studioを使いこなしたい
  • はじめてC#を書くにあたってC#の概要を知りたい

はじめてC#に触れる人がこの本を読むのはちょっとしんどいと思いました。

C#経験が少ない人のことも意識されてますが、網羅的かつ詳細に説明されているだけに、どれも大事なことのように思えて読み終わらなさそうです。優先度の甲乙がつけがたい。

レビューを書く人(自分)のC#歴

C#との接点

  • 2015年夏くらいから業務でWPFのアプリ開発を半稼働くらいで開始
  • 2016年は半分と少しくらいWPFアプリ開発に従事
  • 2017年は7割くらいXamarin(Macアプリと趣味でモバイルアプリ)とWPFとAWS LambdaでC#を触る

読んだ本

  • Xamarin本一通り

あとC#本何冊か部分部分読みました。

特徴的なところ・いいなと思ったところ

似た使い方をする構文の違いの説明が詳しい

  • ジャグ配列と多次元配列のLengthの違い
  • ==Equalsの違い
  • &&&の違い
  • Regexのインスタンスメソッドとクラスメソッドの違い
  • readonlyconstの違い
  • File/DirectoryFileInfo/DirectoryInfoの違い
  • 値型の値渡し、参照型の値渡し、値型の参照渡し、参照型の参照渡しの違い
  • ListLinkedListの使い分け
  • LINQのクエリ構文とメソッド構文の違い
  • 匿名型とタプルの用途の違い
  • interfaceと抽象クラスの使い分け
  • DynamicObjectExpandoObjectの使い分け

本文中で説明されているものもあれば、「エキスパートに訊く」という特設コーナーでQA形式で説明されているものもあってとても勉強になりました。

使っているはずだけど知らなかったことが振り返れる

  • ifwhiledo while{...}省略時の意図していないはずの挙動
  • フィールドの初期化子、コンストラクター、オブジェクトの初期化子の初期化の順番
  • C#6からラムダ式で書けるようになったメンバーの一覧
  • Spritメソッドでseparatorなしの場合はIsNullOrWhiteSpace相当区切り
  • 正規表現で最長一致・最短一致させるための書き方
  • Stackforeachで取り出すときも後ろから取り出す
  • 構造体使用が妥当なケース
  • ハッシュテーブルへのアクセス効率

自明なものとして表立って説明されることはなかったり省かれたりすることが多いけど概念的に大事なことを一言で言い表した上でC#の実装や図表と合わせて説明されている

  • サロゲートペア
  • バッファー
  • コレクション
  • スタック
  • キュー
  • セット
  • ディクショナリ、マップ、ハッシュ、連想配列
  • ジェネリック
  • アセンブリ
  • ストリーム
  • シグニチャ
  • スレッド
  • プロセス

ラムダ式登場の経緯

デリゲート型にをより簡素に書くためにラムダ式が登場した背景が具体的なコードと共に説明された上で、ラムダ式をよく使うLINQの説明がなされていてとても頭に入ってきやすかったです。

この部分に限らず、全体的に単に使い方だけでなく構文登場の背景や、以前のC#バージョンではこう書いていたが今はこう書けるので今後はこう書いていくべきのようにC#をとりまく歴史の中で説明されているので頭がスッキリしました。

全然知らなかった、考えてみたこともなかった…

  • volatile
  • 属性や動的オブジェクト(DynamicObject派生クラス)を自分で定義して使う
  • .NET FrameworkでPythonを動作させる(IronPython
  • マルチキャストデリゲート
  • 演算子のオーバーロード

章毎の確認問題

章毎に理解度を確認するための問題がついています。

コードを書く以外の問題(◯×問題)を掲載するので、試しに確認してみてください。答えが気になる方は是非本でどうぞ!

※章途中の小問題もけっこうあるのでここに掲載する倍以上の問題とその解説が載っています。

  • 1章
    • C#の特徴を「マルチパラダイム」「マルチプラットフォーム」というキーワードを絡めて説明してみましょう。
    • C#アプリは、どのメソッドから実行されますか。また、そのようなメソッドのことをなんと呼ぶでしょうか。
    • 文の末尾を示す記号を答えてください。
    • C#で使えるコメントの記法をくべて挙げてください。また、これらのコメントの違いを説明してください。
  • 2章
    • 次の文章は、C#の基本構文について述べたものです。正しいものには◯、間違っているものには×を記入してください。
    • ( )小数点型は、符号なし型と符合あり型とに分類できる。
    • ( )文字列リテラルはダブルクオート、またはシングルクオートでくくる。
    • ( )short型の型サフィックスは「〜s」である
    • ( )暗黙的な型変換は常に安全なので、桁落ちなどの情報欠落は発生しない
    • ( )メソッド/フィールドなどにアクセスするには、必ずnew演算子でクラスをインスタンス化しなければならない。
  • 3章
    • (省略)
  • 4章
    • (省略)
  • 5章
    • (省略)
  • 6章
    • この文章は、コレクションについて説明したものです。正しいものには◯、誤っているものには×を付けてください。
    • ( )Listへの挿入/削除は、位置に関わらずほぼ一定のスピードで可能です。
    • ( )LinkedListへの挿入/削除では要素前後のリンクの付け替えが発生するので、比較的低速である。
    • ( )HashSetは要素の重複を許さず、一意の値を決められた順序で保持します。
    • ( )Dictionaryは一意のキーと値のペアでデータを管理します。キーの並び順は保証されません。
    • ( )Stackは先入れ先出し、Queueは後入れ先出しと呼ばれるデータ構造です。
  • 7章
    • 以下はオブジェクト指向の主要なキーワードについて説明したものです。正しいものには◯、誤っているものには×を付けてください。
    • ( )フィールド/メソッドは外部から呼び出すことが前提の仕組みなので、アクセス修飾子も既定はpublicである。
    • ( )readonlyフィールドとローカル変数の名前は重複してはならない
    • ( )forループで宣言されたカウンター変数は登場以降、そのメソッドの内部であればアクセス可能である。
    • ( )匿名型はその場限りであれば、引数や戻り値の型として利用することが可能である。
  • 8章
    • 以下の文章はオブジェクト指向構文について説明したものです。正しいものには◯、誤っているものには×を付けてください。
    • ( )派生クラスから基底クラスのコンストラクターを呼び出すには、superキーワードを利用する。
    • ( )virtual修飾子のないメソッドを、派生クラスで再定義することはできない。
    • ( )override修飾子のないメソッドに、sealed修飾子を付けることはできない。
    • ( )as演算子は左オペランドが右オペランドの方に変換できる場合にtrueを返す。
    • ( )インターフェイスを複数実装することはできるが、クラスと一緒に実装/継承することはできない。
  • 9章
    • 以下の文章は本章で学んだ機能について説明したものです。正しいものには◯、誤っているものには×を付けてください。
    • ( )catchブロックは、ブロックで指定された例外と発生した例外とが一致した場合にだけ実行される。
    • ( )クラス/インターフェイス/構造体は、互いに入れ子の関係になることが可能である
    • ( )構造体では、継承は可能だが、インターフェイスの実装はできない。
    • ( )列挙定数の型は、任意の数値型から選択できる。
    • ( )演算子のオーバーライドという機能を利用することで、「+」「-」「==」のような演算子をクラス独自に再定義できる。
  • 10章
    • 以下の文章は、デリゲート/ラムダ式/LINQについて述べたものです。正しいものには◯、誤っているものには×を付けてください。
    • ( )引数にメソッドを引き渡すような用途では、ラムダ式よりも匿名メソッドを利用すべきである。
    • ( )ラムダ式で引数がない場合には、「=>式」のように引数そのものを省略できる。
    • ( )LINQのクエリ構文は、メソッド構文でできることであれば必ず表現できる。
    • ( )LINQでは、与えられたデータソースによってプロバイダーを決定するので、アプリ開発者がプロバイダーを意識する必要はない。
    • ( )LINQのクエリ構文は必ずselect句で終了しなければならない。
  • 11章
    • 以下の文章は本章で解説したテーマニついて説明したものです。正しいものには◯、誤っているものには×を付けてください。
    • ( )スレッドを維持しておくのはリソースの浪費なので、できるだけその場その場で解放するのが望ましい。
    • ( )await演算子は、指定された非同期処理の終了を待ってメインスレッドを待機させる。
    • ( )属性によって適用できる要素は決まっている。
    • ( )dynamic型では、存在しないメンバーを呼び出してもエラーにはならない。
    • ( )イベントを登録するには、「=」演算子を利用する。

目次

意外とネットに転がってない…

  • 1章 イントロダクション
    • 1.1 C#の特徴
    • 1.2 C#アプリを開発/実行するための基本環境
    • 1.3 C#プログラミングの基本
  • 2章 C#の基本
    • 2.1 変数
    • 2.2 データ型
    • 2.3 リテラル
    • 2.4 型変換
    • 2.5 参照型
  • 3章 演算子
    • 3.1 算術演算子
    • 3.2 代入演算子
    • 3.3 関係演算子
    • 3.4 論理演算子
    • 3.5 ビット演算子
    • 3.6 その他の演算子
    • 3.7 演算子の優先順位と結合則
  • 4章 制御構文
    • 4.1 条件分岐
    • 4.2 繰り返し処理
    • 4.3 ループの制御
    • 4.4 制御命令のその他の話題
  • 5章 標準ライブラリ
    • 5.1 文字列の操作
    • 5.2 正規表現
    • 5.3 日付/時刻
    • 5.4 ファイル操作
    • 5.5 その他の機能
  • 6章 コレクション
    • 6.1 コレクションAPIの基本
    • 6.2 リスト
    • 6.3 セット
    • 6.4 ディクショナリ
  • 7章 オブジェクト指向構文(基本)
    • 7.1 クラス定義
    • 7.2 フィールド
    • 7.3 メソッド
    • 7.4 コンストラクター
    • 7.5 クラスメソッド/クラスフィールド
    • 7.6 引数/戻り値のさまざまな記法
  • 8章 オブジェクト指向構文(カプセル化/継承/ポリモーフィズム)
    • 8.1 カプセル化
    • 8.2 継承
    • 8.3 ポリモーフィズム
  • 9章 オブジェクト指向構文(名前空間/例外処理/ジェネリックなど)
    • 9.1 名前空間
    • 9.2 例外処理
    • 9.3 列挙型
    • 9.4 特殊なクラス(入れ子のクラス/パーシャルクラス)
    • 9.5 ジェネリック
    • 9.6 Objectクラス
    • 9.7 演算子のオーバーロード
  • 10章 ラムダ式/LINQ
    • 10.1 デリゲート/匿名メソッド/ラムダ式
    • 10.2 LINQ
  • 11章 高度なプログラミング
    • 11.1 マルチスレッド処理
    • 11.2 属性
    • 11.3 動的型付け変数(dynamic型)
    • 11.4 イベント

独習C 新版

trippieceのCEO、石田言行(いしだ いあん)が本を書いたと聞いて、本くださいとお願いしました笑

というわけで扱い的には生まれて初めての献本。

僕はこの本で言う2012年2月の「trippiece」の成功を決定付けた旅からのユーザで、その体験があまりに刺激的で、鮮明で、楽しくて海外旅行に行くようになったユーザだ。

なので、この本でもメインテーマとして描かれている名前の由来(とそこから導かれる信念のようなもの)は直接聞いたりブログ()で読んだりしてた。

それでもやっぱり知らないことがたくさんあって、ユーザには見せず乗り越えてきたたくさんのことや思いに触れて、本の向こう側にある心境を覗いてみると自然と目頭が熱くなってきた。

そういう本を紹介するとなると過剰に力んでしまってうまく言葉にできないかもしれない。

だから最初に結論を書いてしまうと、20代は負けでいい。新しいことに挑戦し続けよう。多くの人にとってたりない才能とは「高い目標を立て努力を続ける才能」で才能を埋めるための魔法のような言葉が「言行一致」であるということ。

僕が書いたところで文脈が全然違うものになってしまうが、石田言行がどんな男で、どんな思い出、どんなことを成し遂げてきてきたのか。それを知りながら読み進めれば上の言葉はきっとあなたの胸に響き、挑戦しなかった過去を悔い、新たな一歩を踏み出すことになるでしょう。

紹介はここまで!後は本の内容を紹介しつつ、自分が感じたことなどを書いていきます。

trippieceのこと

最初に触れた通り、僕は2012年、trippiece2周年直前くらいからのユーザです。

初めての旅がペルー・ボリビア1週間の旅。

5年間の大学生活の終わり、卒業旅行。どっかめっちゃ遠いとこ行きたい!と思っていたらtwitterでtrippieceとかいうところが40数万円で南米まで連れてってくれると。

でもヤバい!締め切り翌日!夏に親に借金して留学行ったばかりで貸してとか言えないし、1日で40数万円どうやって集めよう…という嘘のようなホントの話がスタートでした。

そのときのブログ(旧)、1日目。

trippieceで行くペルー・ボリビア11日間の旅 ~1日目 豚になったような気分~

言行のブログにも伝説の社畜を目指すすぎちゃんとして紹介されている…笑

このツアーは2回に分かれて行われ、僕はたまたま言行と一緒の組でした。

学生とは思えない落ち着き、交渉力、しかも社長!?この人すげーと思いながらただただお世話になりました。

どんな思い出そこにいたのか、知る由もなかった…

ちょうどその旅のこと、鮮やかに本に描かれてたのでそのまま載っけます。

 参加者は34人。初めて「trippiece」として20人以上を集客することができた。34人を2つのグループに分け、ひとつに僕が参加し、もうひとつのグループにブラジル・スペインに留学経験のある友達とチリで育った友達が参加してくれることになった。

約2週間を見ず知らずの人たちと過ごすことになる。成田空港に5時間前に入り、ドキドキしながらほかの参加者を待っていたのをよく覚えている。ましてや行ったことのない南米だ。

アメリカを経由し、ペルーのリマまでほぼ丸1日。アメリカのトランジットで時間がギリギリになり、ダッシュするトラブルがありつつも、リマに着いた。到着した日はすでに遅かったため、ホテルにチェックインをして就寝。早朝に眠い目をこすりながら、マチュピチュに行くためにクスコという街へ飛行機で向かう。1時間ちょっとも経つと、険しい山々の合間に、街が出てきた。上空から見ても、きれいな街並みだった。クスコはインカ帝国の首都で、世界遺にも登録されている街である。特に、夜の街灯が照らす街の景色は最高にキレイだった。

次の日、いよいよマチュピチュに向かう。インカレイルという列車の駅があるオリャンタイタンボという街まで四駆で1時間半くらい荒れた道を走る。みんなは連日の疲れで爆睡。寝ているうちに、オリャンタイタンボ駅まで辿り着いた。
駅に着くと、マチュピチュに向かう人たちで賑やかだった。日本人も少なくはない。全体の2割くらいが日本人だった。さすが、行ってみたい世界遺産ナンバーワンを獲り続けているだけはある。
インカレイルは予想以上にきれいだった。列車の屋根もビスタドームといって、一部がガラスになっていて、360度の景色を楽しむことができた。車窓から見える渓谷や行商やトレイルをしている旅人たち。約2時間の鉄道の旅は、みんなでお菓子を食べて、お酒を飲みながら過ごしていたらすぐに過ぎていった。マチュピチュが近づいてきた。
マチュピチュ村に着く。もっとなにもないところかと勝手に想像していたが、こじんまりとはしているものの観光客向けにたくさんのショップが並んでいた。マチュピチュには、麓の村からさらにバスで30分ほどかかる。落ちないかとヒヤヒヤする、バス2台分の幅もない道を登っていく。思わず手すりを強くにぎる。

次の瞬間、マチュピチュの姿が見えてきた。見えた瞬間、バス中に歓声が沸き上がった。頂上に着き、入り口をとおると、インカ帝国の遺跡が目の前に広がっていた。写真で何百回と見たマチュピチュが広がっていた。
クスコの街並みにもすごく感動を覚えたが、マチュピチュはここまで来た苦労も重なり、感動は倍加した。みんなが思い思いに写真を撮った。

そして、この旅の終わり。数日後、「死ぬまでにいきたい絶景」として名高い、ボリビアのウユニ塩湖に辿り着いた。待ちに待った絶景が目の前に広がり、涙する。各々、旅行前に考えていたポーズで写真を撮る。美しい景色がどんな写真をも見事な1枚にする。
この1年の苦労が報われた気がした。自分のサービスを使って、地球の裏側まで、ユーザーと一緒に行って、こんなに楽しむことができるという幸せに浸った。
ちなみに前の日程で出発したもうひとつのグループは、僕の参加しない初めての海外ツアーになった。正直、集まってうれしい以上に、なにか起こったらどうしようと不安ばかりが募っていた。
しかし、心配は杞憂に過ぎなかった。多少のトラブルはあれど、12日間の旅が無事終わった報告を受けた。twitterで「 trippiece」と検索すると、「旅はだれと行くかだね。めちゃくちゃ楽しかった。どうにかなってしまいそうでした」「みんなで共有できたことがなにより最高だった」といった感想にあふれていた。
それまで、耐えに耐えてきた想いがあったのだろう。気づけば頬には涙がつたっていた。しばらく、涙ばかりがあふれてきた。ここまで起業して約1年。うまくいかないことばかりだった。僕の伝えたいことが伝わって本当にうれしかった。

この直後に書いてある、「もっとも大事なことは、目にした絶景ではなく、だれかと共有し、感動した体験なのだ」という言葉。ここにtrippieceの魅力が凝縮されていると思います。

初めてではあれ、同じ目的を持っていた人が集まり、旅へと出かける。

初めましてで始まり、また飲もうなで終わる旅。

絶景はもちろん素晴らしい。一人旅も悪くない。それ以上に常にハイでいられる仲間と乗り越えていくトラブル笑とか、そういうよくわからんものが何より楽しい。

僕は高まると文章を書きたくなるので、毎晩毎晩ブログ書いていました。

人生の中でも最高級の旅の思い出でした。

そういう旅ばかりと思いきや、バンジージャンプ、スカイダイビング、カラーラン(にみんなで一緒に行く)等々、1日から気軽に参加できるアクティビティも充実しています。

trippiece
RETRIP

言行のこと

そんなtrippieceを率いる石田言行(いあん)。誰もが最初は変わった名前やな〜と思うと思うんです。

そこに込められた並々ならぬ想いに触れると名前が愛おしくなります笑

” target=”_blank”>ブログの方から拝借。

言行へ

 パパとママは、キミがどのような思いをこめて「言行」と名付けたのか。将来、これを読んでくれることを楽しみにして、生まれたてのキミに書き記すことにしました。
 キミの名前は、パパがつけました。それは、キミがまだおなかにいるときに、生まれてくる子が男の子だったらパパが、女の子だったらママが名前をつけようと決めていたからです。(ちなみにママは、女の子が生まれたら「未来」(みく)と名付けるつもりだったようです)(パパは、絶対に男の子が生まれてくる、と確信していましたし、熱望していたのです)
 では、パパが「言行」と名付けた理由をこれから話しましょう。パパはまず、名前を考えるにあたって、3つの基準を持っていました。それは、

①とにかく人と違う名前であること(いうまでもなく、名前はいちばんの個性ですから、目立つほうがいいと思っていました)②外国人も呼びやすい、インターナショナル名前であること(キミが外国にいったときに覚えてもらいやすいように)③そして、名前に意味があること(単なる当て字や語呂合わせで意味のないものだけは避けようと思っていました)
 以上の3点です。

 そして、これらの基準は別にして、パパは、男だったらこうなってほしいな、という理想像を頭に描いていました。それは、“優しくて、強くて、かっこよくて、女にモテる男”です。実は、キミの名前が決まってのは、この“男の理想像”を考えていたときでした。
 ふと頭の中に、とつぜん、パパが子供のころに好きだったテレビ映画『0011/ナポレオン・ソロ』のふたりの主演俳優―ロバート・ボーンとデビッド・マッカラムの顔が浮かんだのです。そして、このふたりの俳優を思い出した次の瞬間に、キミの名前は決まりました。
 「イアン・フレミング・・・・・・。そうだ、イアンがいい!!」 イアン・フレミングというのは、イギリス人の作家で『0011~』をはじめ、有名な『007シリーズ』の原作者です。
 『0011~』は、パパが3~4歳のころにやっていた作品です。なぜそんな幼いときの記憶があるかといえば、それはきっと、パパとパパのママが、当時ブームだった秘密情報員(要するにスパイ)が登場するテレビや映画が大好きで、一緒にみていたせいでしょう。だからこそ、イアン・フレミングという名前がすぐに思い出せたのだと思います。

 イアン―――いあん。瞬間的に、名前はこれしかないと思いました。
 名前をつける基準と照らし合わせてみても、①の“人と違う名前”も②の“インターナショナルな名前”もクリアーしています。
 なにより、パパが願う“理想像”としても、イアン・フレミングが自分の作品に描く男は『0011~』に登場するソロ、イリヤ・クリヤキン、『007』のジェームズ・ボンド――いずれも“優しくて、強くて、かっこよくて、女にモテる男”です。
 こうして、「言行」という名前は、はじめに文字からではなく、「いあん」という音が先に決まりました。そしてその次に残る基準の④を満たす“名前に意味がある”文字を考えたのです。

 「言行」は「言」を「い」と読むのも、「行」を「あん」と読むのも、どの国語辞典を探しても載っていないと思います。しかし、どちらも当用漢字ですから、「言う」、「行脚」、「行燈」などと一般的に使われているように、決して無理な読みかたではありません。
 でも、パパにとっては、辞典に載っていようといまいと、「言」を「言葉」として、「行」を「行動」という言葉の意味として、それぞれの文字が必要だったのです。
 つまり、「言行」という名前は、「言葉と行動」という、パパが最も重要だと思っていることを、ひとことで表したものなのです。

 「言葉」について――。
 いうまでもなく、人間は、たったひとりの力では誰も生きてはいけません。毎日の食べるものも、着るものも、勉強することも、スポーツを楽しむことさえも、他人の助けを得なければ生活することのできない生き物なのです。そのために、人間には、地球上の動物で唯一“言葉”を話す(会話)という能力ができたのです。
 ですから、言行には、自分を支えてくれるすべての人との会話を大切にしてほしい。
 会話によって、キミが相手に助けられることもあれば、キミが相手を助けることだってあるのです。相手が黙っていたら、キミはその相手を理解できないのと同じように、自分が言葉を発して意志を伝えれば、相手はキミの存在を確認してくれる、ということです。
 要は、間違ったり、失敗することをおそれずに、キミの心の内を言葉として話してほしいのです。

 「行動」について――。
 パパの座右の銘は、“前進なくして進歩なし。命をかければなんでもできる”というものです。これは、パパのパパから学んだ石田家の“座右の銘”でもあります。パパは、うまく事が運ばない時や、悲しい時など、いろいろな壁につきあたった時に、この言葉を思い出しては心の励みにしてました。
 人間の心というものは、このような悩んでいる時には停滞しているのです。だから、何かを解決した、とか、壁を抜けだしたい、と思ったら、前へ前へ、と前進するのが、いちばんの方法なのです。そして、ひたすら努力をする。
 人間、命をかけるほど努力をすれば、できないことはなにもありません。もしできないことがあったとすれば、それはまだまだ努力が足りない、ということなのです。
 これは、簡単にはいえますが、実際はものすごくつらく、大変なことです。努力しないことへの言いわけは、自分自身でいくらでもつくれますから。でも、結果がすべて自分に還ってくるのも“前進”と“努力”です。
 言行も、いつか壁につきあたったら、この言葉を思い出してください。そして、とにかく行動しつづけることを忘れないでください

一九八九(平成元)年九月二十四日 記

変わった名前であるがゆえに小頃にはからかわれたり嫌なこともあったようですが、この上ないルーツ。

名前負けしてないとは端から見た感想で、本人はまだまだと思ってるっぽい。

いい意味で読者への挑戦的なメッセージが多いけど、その度に自分はそう言う資格があるかわからないけど的な入りで、それは群衆向けの言葉ゆえの配慮なのかもしれないけど、そういう面なんか彼らしくてニヤニヤしてしまいました笑

新しいことに挑戦し続けるということ

全体的にこの「新しいことに挑戦し続けるということ」に対して畳み掛けてくる。

これでもかってくらい笑

でも、それは自信の経験から出た言葉であったり、家族の思い出あったり、大学の恩師や先輩の言葉であったり、先輩起業家の言葉であったり、過去の偉人の言葉であったり。

でもやっぱり、言行自信のこの言葉が一番響くのでやっぱり引用したい。

今、どれだけあなたが負け続けていたとしてもかまわない。「大言」を掲げ、黙々と「実行」していくことを諦めなければ、起業家にだって、一流にだって、なににだってなれる。最後には、勝てる。負け続けている僕自信も、そう信じている。
 多くの人にとって、足りない才能とは、「高い目標を立て努力を続ける才能」だと思う。そして、その才能を埋める魔法のような言葉が「言行一致」という言葉なのだ。

これだ。ほんとにこれだ。

人生はなにもしなければ、当たり前だがなにもない。つまり、意味付けしなければ、無目的なのが人生だ。

人生を賭けるのに値するのは夢だけだ

僕は転職して、小さい頃言ってたのと全然違う、大学の専攻とも微塵もかすらないプログラマーになった。

サービス自らの手で生み出すエンジニアかっこいい!俺も何か作って世界変えてやんよへへん!みたいな思いからだ。

とはいえ、最近は中高生でも尖ったプログラマーは相当数いるし、基礎・学のあるプログラマーとかインターンでも足元に及ばない…

そんな中思っていたよりも成長が速くないし、仕事でやる以上優先すべきこと(分野)もあるし、けっこうしょっぱい。不安にもなる。

それでもどうにかしてやるという勇気が湧きました。

無難に着地させようとしたら失敗もないのかもしれないけど、成功もない、なんでもないような20代を終えてしまう。

小説を読みました。

内容にも触れてます、お気をつけて。

パラレルワールド系恋愛小説。

電車の時間は大体技術書を読む、読まざるを得ない、読みたい。

ただ、電車の乗り換えの関係で1駅しか乗らない短い時間、寝る前は技術書じゃない本を読む。

前置き

ゴールデンウィークには森見登美彦さんの『夜は短し歩けよ乙女』を読んだ。

{ 先輩: ♂, 後輩: ♀ }の2人の主人公の視点で交互に繰り広げられるこの小説も恋愛調節なのだが、先輩の必死さ、後輩の無邪気さ、舞台である京都の雰囲気、コミカルさ、想像上の視覚の色鮮やかさ、そして何よりも最後に包まれるほっこりとした雰囲気に改めてたまに小説もいいなぁと思った。

はじめて森見登美彦さんのは大学生の頃で『太陽の塔』というお話。

当時ものすごい失恋をして、半年くらい立ち直れなかった気がする、そんな状況で読んだら吹っ切れられたような気がする、そしてこの作者ふられた人に教えてもらった気がする。

どこまでも面倒見がいい。

恋愛とか恋とかのなんかこうきゅっとなる、そういう世界から遠のいていただけに、夜は短しは久々にグッときた。

次なに読もう?

そう思った矢先、Facebookでこの本のリンクをはっている方がいらっしゃったので何となく買ってみた。

最後のページにはこう。

京都の美大に通うぼくが一目惚れした女の子。高嶺の花に見えた彼女に意を決して声をかけ、交際にこぎつけた。気配り上手でさびしがりやな彼女には、ぼくが想像もできなかった大きな秘密が隠されていてーー。「あなたの未来がわかるって言ったら、どうする?」奇跡の運命で結ばれた二人を描く、甘く切ない恋愛小説。彼女の秘密を知ったとき、きっと最初から読み直したくなる。

いかにもな感じ。

これ、オチ言ってるやん…秘密知った上で読んだら、読み直すも何もないやん…

そう思いながらページをめくり始めた。

最後の方にはもう大体枕に顔うずめて泣いていた。

最初から読み直すことはないけど、最初から読み直したくなった。

一目惚れした女の子は時間が逆に流れる別世界から来た人。話は互いに20才のときに繰り広げられるが、5年経つと{ 男の子: 25歳, 女の子: 15歳 }になる。

女の子の世界は時間が反対に流れるので、女の子には男の子にとっての未来のことしか記憶にない。だから男の子は明日、昨日のきみとデートする。

女の子はこちらの世界に5年に1度、40日間しか滞在できない。

男の子が女の子に意を決して話しかける日こそが女の子にとってのこちらの世界最後の日になる。

男の子が初めて手を握るとき、初めて呼び捨てにするとき…男の子にとってのその1つ1つは女の子にとっての最後でその度に泣く。男の子は女の子がおき忘れた日付が逆さに進んで行く手帳を見つけ、知ることになる。

ふたりの歴史を壊さないために、別れる日に男の子が女の子に40日間すべてのことを話すことを。

そして女の子はその筋書き通りの行動をとることを。

男の子はそれを「演技」だとして一度は愕然とするものの、お互い思いやりは強く…というお話。

「演技」の奥にある、「演技」をしても守りたいもの。大切な相手を愛おしく思う気持ち。限りあるとわかった上で歩んで行く1日、また1日。

そのどれもが綺麗で切なくて儚くて、中くらいの大人が泣いてしまった…。

恋愛という文脈ではないですが、恋愛という文脈ではないですが、恋愛という文脈ではないですが、最近ルームシェアとかしてるといろいろ感じるんですよ。

ただただそこにいる人が「大切」であるという感覚。

自分が引きこもりたいような気持ちのときとか、イライラしているときとかは当然あってむすっとした感じになっているときはあるけども、そんなときですらなんとなく大丈夫だと思えてしまう強さ。

を勝手ながらもらえる。

シェアは一応2年という契約期間があって、それが気持ちに拍車をかけている面もあるのかもしれない。

それでも大学で東京に出てきて以来の一人暮らしをやめ、人と生活するというのは、人として持っていたい感情に気づかせてもらえた尊い経験のような気がする。

小説の話、文脈に戻ると、「演技」から伝わってくる相手を思いやる気持ちがほんとに胸に響いた。

そういうときは無性に文章を書きたくなる。

思いの象徴としての行動は簡単にとれる。仕事でも何でも、仮に気持ちはなくても、気持ちがあるように態度で示せる。

けど、真意として何を守るための行動かで世界の中でその行動が持つ意味は全然違う。

この文脈でこの記事ほんとに出したくないけど、こういうことでもある。

LINE(株)CEOを退任した森川亮氏が明かす!「優秀な人」ほど喧嘩をしない理由

思いを見つめながら生きていきたい。

7月7日(月)

今日はこんなタイトルのお話を聞きに行って来ました。

【StartupWeekendTokyo x DevLOVE】イケてるスタートアップの開発現場の話が聞きたい!

スピーカーは下記の方々です。

①KAIZEN platform Inc. 技術顧問 伊藤 直也氏

ニフティ、はてな取締役CTO、グリー統括部長を経てフリーランスとして活動。ブログやソーシャルブックマークなど10年間、ソーシャルメディアの開発と運営に携わる。著書に『入門Chef Solo』(達人出版会)『サーバ/インフラを支える技術』『大規模サービス技術入門』 (技術評論社) など多数。2013年9月よりKAIZEN Platfrom Inc. 技術顧問。

②SmartNews代表取締役 浜本  階生氏

2005年東京工業大学工学部情報工学科卒業。ソフトウェアエンジニア。2007年に『EatSpot』で価格.com WEBサービスコンテスト最優秀賞、2009年に『Blogopolis』でYahoo! JAPAN インターネットクリエイティブアワード 一般の部 グランプリなど受賞多数。共訳書に『実用Git』(オライリー・ジャパン)など。Webに氾濫する情報の整理、可視化に興味を持つ。

③nanapi CTO 和田 修一氏

株式会社nanapi 取締役CTO。経済学部を卒業後、2005年楽天株式会社に新卒で入社。サーバやストレージなどのインフラ周りの設計・運用などを担当。2009年に株式会社nanapiの取締役CTOに就任し、主にnanapiの開発に携わる。技術面の得意分野はいろいろなミドルウェアを活用したシステム設計など。現在は、技術分野だけでなく取締役として経営・マネージメントなどを担当。

http://swtokyo.doorkeeper.jp/events/12769

とても勢いのあるスタートアップの技術系の方々のお話ということでめちゃくちゃ楽しみにしていました。

まずはお三方の講演ということで、発表資料を。

①KAIZEN platform Inc. 技術顧問 伊藤直也さん

Kaizen platform Incのマネジメントのお話。

あらゆるツール(情報共有のツールからInfrastructure as Code、リモートワーク)の活用というハード的側面と情報共有、コミュニケーションといったソフト側面。

印象に残ったのは2つで、

マネジメントとは管理ではなく支援。コントロールするのではなく力を発揮できるように支援する。

というあり方。

もう1つは、ご自身の↓のツイートも引用しながらのマネジメントについて。

フラットで一見ノーマネジメントであっても、その組織なりのマネジメントは必要ということ。

かっこ良過ぎです。

恥ずかしながら技術的なお話の細部まではわかってないんですが、上に立つのがこういう方なら技術を大事にでき、安心して(≠甘えて)開発できるのかなぁと思いました。

②SmartNews代表取締役 浜本階生さん

・「SmartNewsらしい」開発とは何か
・なぜ、それを大事にしたいのか
・それを守るために何をしているのか

というお話。

タイトルがSmartNewsに「おける」開発の考え方というところに、感じるものがありましたが、具体的にどういう部分がそれにあたるのかはスライドを見てみてください。

経済合理性に基づいて意思決定していけば、誰でも同じものに辿り着く。常識を少し外れたところに真の優位性が生まれ得る。

僕が何か生み出してるわけではないですが、この部分になるほど〜と思いました。

経済合理性の仕組みの上に人の嗜好が乗っかっているもの、平たく言えばキュレーションってうまくバランスとっているのかなぁと思います。

③nanapi CTO 和田 修一さん


和田さんのスライド追加しました!(2014年7月8日)

nanapi(ロケットスタート)創業からの開発体制の変遷にはじまり、技術を大切にする社内文化の醸成のお話へ。

ちょっと前にこの記事を読んで素敵だな〜と思っていたのですが、やっぱり素敵でした笑

技術を軸とした文化をつくりたいーnanapi CTO和田氏の“プログラミング教育”とは?

具体的には
・メンバーへの意識付けとして自社で使っている技術をアウトプットする
・情報共有ツールは用途を限定せずとにかく使わせることが大事で、ツールが風土を築く。社内の風土にあったものが選定されるべき
・時代に合う技術を柔軟に身につけていくべき

というところです。

これは講演後のQ&Aの部分でのお話ですが、

ツールのに詳しい人は自分以外にもいる。自分がすべきことは、エンジニアに最短で導入できる道を準備してあげること。それは、必要以上のプレゼンをさせず、予算をつけてあげることだったり…

という趣旨のくだりが印象的でした。

規模によって体制や適したマネジメントはかわるかもしれませんが、そもそもその組織の上に龍人がどういう考えを持っているのか、どういう社内文化、風土を作りたいのかという部分はめちゃくちゃ大事そうです。

外からではほとんど見えないし、実際触れてみないとわかるところまではいかないかもですが、垣間みることができてよかったです。

6月3日(火)

毎年カリフォルニアにおいて開催されるApple主催のデベロッパー向けイベント。

「WorldWide Developers Conference」

今年も日本時間6月3日AM2時に開催されました。

140403_wwdc_2014

●期待された新端末

今回の発表に先立ち、色々な噂が。こんな記事も出ていて、iPhone6やウェアラブル端末の登場に期待が高まっていた雰囲気。

iPhone 6の特徴がよく分かる! モックアップとiPhone 5sの比較動画

駄菓子菓子!実際はハードの発表がなくて残念…って方も多かったのではないでしょうか。

そっちは9月頃なんでしょうかね。
アップルは今年後半に“最高の製品ラインアップ”を発表する

●じゃあ実際何が発表された?

もちろん、概要を伝える似たり寄ったりな記事は量産されてますし、最新OSの発表、APIの公開、ヘルスケア系社員の増員からの期待を裏切らないソフト、iOSとOS Xの連携、sfariの高速化等々あっそ〜なものから楽しみ!なものまで玉石混交です。

その一方で、新言語Swiftについては大きなメディアにとどまらず、個人単位で注目する記事が多いような気がします。

●新プログラミング言語、「Swift」の登場

apple-swift-logo

これまでiOSのネイティブアプリ向けにはObjective-Cが主流でしたが、Swiftがこれに置き換わっていくのではないかと。

既にFacebookページも。
・Swift
https://www.facebook.com/pages/Swift/1475908685980132?fref=ts

・SWIFT Programming Language
https://www.facebook.com/swiftprogramminglanguage?fref=ts

たくさんの記事。

・MacOS 10.10 Yosemite、新プログラミング言語Swiftが発表!さてさて・・・
http://ch.nicovideo.jp/akiba-cyberspacecowboys/blomaga/ar545898
→姿勢に拍手。ただただかっこいいです。

・Swiftバズがすごいことになってる-WWDCキーノートのメモ
http://f-shin.net/fsgarage/1716
→藤川真一さんの記事。なんとなくバズに流されるだけではいけないと…

この方の著書にかなり刺激を受けました。

・早速Swiftで書かれたFlappySwift
https://github.com/gscalzo/FlappySwift
→早速GitHubに上がってます。単なる速報は見飽きたけども、作るってすげぇ…

・[iOS] 新言語SwiftがObjective-Cよりも良いところ
http://qiita.com/nori0620/items/cf956fea84e82ec2aee5#2-7

・Swift ファーストインプレッション
http://mizchi.hatenablog.com/entry/2014/06/03/174739

・Objective-Cに替わる新しいプログラミング言語Swiftの登場
http://dev.classmethod.jp/smartphone/swift/

・言語仕様もiBooksにて既に無料配布
https://itunes.apple.com/jp/book/swift-programming-language/id881256329?mt=11

●感想

「エンジニア」に憧れるがゆえにこういう情報を見たら過剰に反応してるだけかもです。

ても、たくさんのAPIが開かれ、それを実装するのにふさわしい軽量に動作する言語まで準備されてるなら、触れてみたい、何か作ってみたいと情熱がわき上がるのは割と自然なこと。

よりよりハードは追究されながらもソフトウェアドリブンな世界で自由に動き回るべく成長を急ぎたいところです。

4月20日(日)

●今なら『ツイッター創業物語』が無料でダウンロードできる!?

日経グループが運営する電子書籍販売サイト「日経ストア」で
『ツイッター創業物語 権力、友情、そして裏切り』
を無料で配布しています。
http://pr.nikkei.com/ebooks/campaign/twitter/index.html?n_cid=STORE234

普通に買うと1,944円のようで、かなりの大盤振る舞いですね!

先着1万名で、ブログを書いている時点で残り4,000冊弱。

●やっぱり「タダ」ではダウンロードさせてくれない…

ただ、ダウンロード完了までの手順が鬼のようにめんどくさいwwwww

必要な手順はざっくりと下記の通り

・日経ID取得
 持ってたら不要。でもどれがどれだか…

・日経ストアアプリのダウンロード
 電子書籍のビューアーアプリでなくて?しかもMacには非対応。ビューアーアプリ乱立させないでほしいだれか統一して!

・書籍のダウンロード×2
 http://pr.nikkei.com/ebooks/campaign/twitter/index.html?n_cid=STORE234
このページからダウンロードして、更にアプリの中でダウンロード(一時的にダウンロードしたファイルを見れるする)する必要…

いやぁ。うーんって感じですね。

使い勝手の悪いモノは増やさなくていい。

それでも2,000円くらいする本(質は知らん)をタダでもらえるならダウンロードしちゃいましょう!

GIGALINEさんが手順をまとめてくださってるので、そちらを見ながらぜひ!

1944円の電子書籍「ツイッター創業物語」を無料で日経ストアからゲットする手順

4月7日(月)

イケダハヤトさんの新刊、『なぜ僕は「炎上」を恐れないのか』を読みました。

ikedahayato-book
なぜ僕は「炎上」を恐れないのか~年500万円稼ぐプロブロガーの仕事術~ (光文社新書)

「あなたも今日から燃えてみないか?」と、帯もなかなか挑戦的ですが、まとめるといい話でした。

ざっくりまとめると、
・はっきり意見言おう
・そのために言っても許される環境築こう
・環境を築くためには情熱を持って圧倒的な時間を効率的に投入しよう
・それには運もあるけど、確立を高める方法だってある
・炎上=悪いことってことでもない
・情熱を持てることが見つからなかったらボランティアやってみよう

ということ。

上がプロブロガーとしての地位を築き上げているイケダハヤトさんの
実体験をふんだんに折り込んで語れています。

その中でも特に印象的だった部分をご紹介。

・「いいね!」の新しい捉え方

「新しい価値観」というのは、その新しさゆえに
同時代においては決してすぐには受け入れられないものです。
ある意味、誰もが「いいね!」ボタンを押すようなものは、誰もが理解可能であるという意味で、何も新しくないのです

これは救いですね。

ブログ書いてたらやっぱり読んでもらってなんぼ。

いいね!には多様な意味がありますが、「読んだ!」的な意味もあると思うので全然増えないと萎えます笑

ただ、もちろんほんっとにしょうもないと思ったらいいね!とかつけないだろうし、逆によくわからんし賛否の別れるものなら賛側や野次馬側のいいね!はつくでしょう。

…というわけで、広告収入重視のスタンスからリーチが短くなったFacebookでいいね!がつなかくても、こういう解釈もあるという前向きな姿勢で書き続けようと思います。

・えらそうなこと言いたいなら…

「何者もおそれない強い心」を身につけるのに最も手っ取り早い方法とはなんでしょうか?前章の最後に書いたとおり、それは「圧倒的な地位」を確立することです。
地位を獲得するということは、あなたが戦う市場において「あなたがいなければダメなんだ」と、できるかぎり多くの人に感じてもらえるようになるということです。裏を返せばそういう唯一無二の存在にならなければ、あなたの発言力は落ちてしまいます。

何と言うか…身も蓋もない正論ですね笑

率直に物事を申し上げたいこちら側も、それを聞く相手も人間だもの。

相手を尊重する、というか率直に物事を申し上げたら相手がどう思うのかは想像できるはず。

尊重し過ぎてもはっきり言えないから困るわけですが、だからドヤれる地位を築こうと。

それできなかったら、何言ってもただのわがままな気がするので前提として肝に銘じておきます。

ただ、そのためにはどうすればいいかもちゃんと書いてるほんなのでとても親切だなぁとしみじみしました。

イケダハヤトさんの著書読んだり話聞いたりしたことないときって、漠然と「炎上ブロガー」「なんか言葉きつそう」くらいのイメージしかなかったんですが相当印象が変わると思います。

実際親切です。

・まっすぐな情熱がまっすぐな思いから生まれるとも限らない

環境に恵まれることがなく、「自分の存在を認めてもらいたい」「意味のある人生を送りたい」「ここから逃げ出したい」という強烈な思いを抱くことになった人は、現状に満足して平穏に生きている人よりも、一流になれる可能性を秘めています。不遇は、「恵まれている」と考えることもできるのです。

これ、沁みます。

僕自身がまさに去年色々と悶えた時期があって、就活の時期以上に自分を穴があくほど見つめ直し、苦しんだ結果「今」があります。

その「今」って何やねんって感じですが、人生始まった感があるくらい大事な大事な「今」を歩んでいると思っています。

この先もきっと、うわ、マジで、ぐぬぬっていう時期が何度も来るとは思うんですが、それは「恵まれている」ことでそのときのそのときの自分にとっての「今」を育んでくれるものになるでしょう。

・最近思うこと

最近、物事はっきり言おうぜ。

本心で生きようぜ的なものがよく目につきます。

「そんなん前からけっこうあるじゃん」

とか言いたい人。ちょっと待って。そういうこと言ってんじゃない。

何かこう、自分がもやもやしてること、探してること、そういうものに対して人の感度ってすごく高まると思うんです経験上。

だから逆に、よく聞こえることの裏返し。

「はっきり主張してなくない?」
「俺の意見ってないがしろにされてない?」
「そんな人生でほんとにいいの?」

がある状態なんじゃないかと。

今回はそれをすごく自覚してたんですが、よく聞く気がする!って感じることから自分の状態を逆にあぶりだすのって大事な気がしました。

そんな自分のアンテナに引っかかった作品達を最後に紹介して今回の記事を追えようと思います。


これは映画を見ました。


北川景子かわいい。

だけではない。


騙されたと思って読んでみてください。