kakakakakku blog

Weekly Tech Blog: Keep on Learning!

2017年の振り返りと2018年の抱負

日記

2017年の振り返り

積極的に実戦投入をした

2016年から2年連続で目標にしている「実戦投入力を高める」を達成できた．規模の大きかったプロジェクトを挙げると以下の通りになるけど，他にも多くの実戦投入をしていて，1年前と比べても成長を感じることができた．技術的な「実戦投入」だけではなく，組織的な「実戦投入」も経験できた点がポイントだと思う．

  • MySQL 5.5 on EC2 から Aurora に移行をした🎉
  • Elasticsearch 1.4 on EC2 から Amazon ES に移行をした🎉
  • Go + SQS + ECS でマイクロサービス基盤を複数構築した🎉
  • 新規プロジェクトでスクラムマスターを兼任してアジャイル開発を推進した🎉
  • 技術広報を兼任して技術的に注目される組織とは何かを突き詰めることができた🎉

1年間を通してブログのネタが尽きることがなく，まだまだ書ける余力を残していたし，様々な技術領域で登壇できたことも「実戦投入できた証」だと思う．定量的に評価することは難しいけど「実戦投入力を高める」という目標は本当にオススメ！

様々なスタイルで技術を「教える」ことに挑戦した

2017年は「技術支援を仕事にする」という目標も立てていて，「技術を教えるための基礎力を整える1年間」と位置付けていた．結果的には大幅に達成できた．まず，副業として TechAcademy で Rails 講師（具体的には，ウェブアプリケーションコースのパーソナルメンター）を1年間担当して「約30人」の生徒さんを卒業させることができた．プログラミングに挑戦したいという熱意を持った生徒さんに「教える」のは本当に楽しく，僕自身も刺激を受け続けていた．たまに「教える = 技術貯金の切り崩し」と表現されることもあるけど，そんな感覚はなく，教えながら気付く「プログラミングの難しさ」に対して，様々なアプローチを実践できた．このあたりは別途まとめる予定．

techacademy.jp

次に「Redash ハンズオン資料」を作成し，公開できたことも「教える」という目標に対するアプローチだった．さらに話が広がり「ハンズオンイベント」を開催できたことも大きな成果だった．詳しくは以下の記事にまとめているのと，今月末にも再演を予定している（これもまた既にキャンセル待ちになってしまっている）．

kakakakakku.hatenablog.com

さらに「教えるには様々なスタイルがある」と気付けた1年でもあった．ブログを書いたり，イベントで登壇したりするのも，本質的には「教える」に繋がっていて，2017年は多くのアウトプットを通して，様々な人に「教える」を届けることができたと思う．さらに，11月頃から「ブログメンター」という個人活動（無料）も始めていて，この話もそこそこの成果が出たら，まとめてみようと思っている．

英語

英語に関しては，未達成だった．2017年こそ re:Invent / SREcon など，海外カンファレンスに参加して，チャンスがあれば登壇もしたいと考えていたので，そのために「DMM 英会話」に入会したけど，結局のところ海外カンファレンスに参加するチャンスがなく，約半年間でレッスンを受けなくなってしまった．とは言え，半年間は「DMM 英会話」だけじゃなくて「社長との月次面談を英語で実施する」という試みをしてみたり，iKnow! を毎日コツコツ進めたりもしていた．あと，11月に数年振りに TOEIC を受けてみて，またモチベーションが戻ってきているので，今月開催も申し込んである．

インプット／アウトプット

登壇

登壇は計14回で過去最高だった．既に記事にまとめているけど，2017年の目標にしていた「LT 以外にも挑戦する」という点も達成できた．プレゼン芸人と言われることもあり，多少なりとも登壇を通してプレゼンスを高められたと思う．

kakakakakku.hatenablog.com

勉強会

勉強会は計15回参加した．2016年の21回と比べると減ってしまっているけど，それでもいろいろと参加できたし，登壇者として参加することが増えたのも良かった．

プルリクエスト

OSS に送ったプルリクエストは計12回で過去最高だった．

kakakakakku.hatenablog.com

ブログ

「週1回」のノルマを達成して，計77記事を書いた．また，ブログをテーマにした登壇をする機会もあり，改めてアウトプットを習慣化することの重要性を認識することができた．

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

Google Analytics で PV を見ると，去年比で「約2倍」に増えていた．ホッテントリに入ることも多かったけど，検索流入も増えていて，2016年よりも需要のある記事が書けたと思う．

f:id:kakku22:20180102025544p:plain

読んだ本

毎月1冊は読みたいと思っているけど，読むのが遅く，積読が増えてしまうという悩みは引き続きある．

2018年の抱負

2018年は大きく2個の目標に決めた．どちらも2017年の継続になっているけど，単なる継続ではなく「圧倒的に深みを出す1年間」にする．

（継続）実戦投入力を高める

過去2年間「実戦投入力を高める」という目標を立てて大きく成果を出せているため，3年連続の目標にする．今までは「技術的負債の解消」をテーマに実戦投入をすることが多かったけど，2018年はもっと視野を広く持ち「クラウドネイティブなスケーラビリティとは何なのか？」を意識しながら実戦投入をしたいと思う．技術トレンドに取り残されないように，常に成長し続ける．

（継続）技術支援をメインの仕事にする

振り返りにも書いた通り，2017年は「技術を教えるための基礎力を整える1年間」と位置付けていた．2018年は本格的に動き出す1年にしようと考えていて，技術支援をメインの仕事にしていくためにアクションを積み重ねることを宣言する．キャリア・アンカーで自分自身の志向性に気付かされたこともあり，プロダクト開発とは違うスタイルで技術力を活かすことができるし，その方向性に需要があることも2017年を通して肌で感じることができた．

また「技術支援」の一環として，2017年にやってきたような「アウトプットの重要性を伝える登壇」をしたり，「アウトプットに悩む人のメンターになる」ことも継続する．例えば，社内勉強会にゲスト登壇するという形でも全然良いので（無料），もし需要があれば気軽に連絡をくださいませ！

まとめ

2018年も攻めていくぞ👍

過去の振り返り

2017年のプルリクエストを振り返る

GitHub

年末なので，今年も OSS に送ったプルリクエストを振り返っておこうと思う．ちなみに去年からプルリクエストの振り返りをしている．

kakakakakku.hatenablog.com

2017/01

  • alexanderzobnin/grafana-zabbix

運用している Zabbix のダッシュボード部分を改善するために grafana-zabbix を導入して，機能を細かく調べているときに発見したドキュメントのミスを修正した．

github.com

  • pandeiro245/245cloud

ポモドーロを回すときに，たまーに 245cloud を使っている．これは Rails で実装されていて，さらに OSS になっているので，コードを読むために環境構築をしたら seeds.rb でエラーになり，困ったので修正した．

github.com

2017/03

  • getredash/redash

Redash のモニタリング用メトリクスで，Redis 関連のキー名が適切ではないことにハマり redis_used_memory と redis_used_memory_human を分離した．まだマージされてないけど，これは必要だと思っている．

github.com

  • rakuten-ws/rws-ruby-sdk

楽天 API の Ruby ラッパーを使っていたら，レシピ検索のランキング取得でドキュメントと異なる I/F になっていることに気付き，カテゴリーを指定しない場合は総合ランキングを取得できるようにした．

github.com

2017/04

  • getredash/website

Redash で REDASH_ALLOW_SCRIPTS_IN_USER_INPUT 環境変数の挙動を確認していたときに，ドキュメントに書かれているデフォルト値が違ったので修正した．

github.com

2017/05

  • silinternational/ecs-deploy

ECS のデプロイに使っている ecs-deploy の typo を修正した．ecs-deploy は shell で実装されているので，AWS CLI と shell 芸を学ぶ題材としてもオススメ．

github.com

  • mackerelio/mackerel-agent-plugins

mackerel-plugin-nginx で使える -header オプションがドキュメントに書かれていなく，修正した．UserAgent を指定して送る処理を書いているときに気付いた．

github.com

2017/06

  • apex/apex

Apex で Lambda をデプロイするときに使える --env オプションに typo があり，ハマったので修正した．

github.com

2017/11

  • fluent/fluent-logger-golang

Go から Fluentd にログを流すときに使う fluent-logger-golang の README に書かれてるサンプルコードが動かないことに気付き，修正した．

github.com

  • getredash/website

Redash ハンズオン資料を作りながらドキュメントを見ていたら，文字サイズ指定のドキュメントが間違っていたため，修正した．

github.com

  • robbyrussell/oh-my-zsh

突然 oh-my-zsh の Composer Plugin で警告が出るようになってしまって困ったので，推奨されているクォートの対応を追加した．oh-my-zsh のプルリクは既に800件以上も溜まっていて，見てもらえるような状態ではなさそう．

github.com

2017/12

  • silinternational/ecs-deploy

ECS のデプロイツール ecs-deploy の Fargate 対応をした．まだエッジケースの対応が残っていてマージされてないけど，Fargate が東京リージョンで使えるようになるまでには対応したいところ．

github.com

まとめ

今年は計12個で，実際に仕事で使っているサービス／ライブラリに対するプルリクエストがほとんどだった．ドキュメント修正は結果としては簡単に見えるけど，詳細に使いながらドキュメントを読み込んでいるからこそ気付けるもので「実戦投入力を高める」という年間目標に合っていると思う．また，アドベントカレンダー駆動学習で頑張った ecs-deploy の Fargate 対応は，多くのフィードバックコメントをもらうことができて，非常に楽しかった（まだマージされてないけど）．来年も引き続きプルリクエストを送れるように頑張っていくぞ！

ハンズオン講師を担当した Redash Meetup を振り返る

Redash 勉強会

今日は「Redash Advent Calendar 2017」25日目の記事を書く．参加者が集まらなかったらどうしよう...と不安を抱えながらも公開したアドベントカレンダーだったけど，気付くと全枠埋まっていて，さらにどの記事も素晴らしく，とにかく最高だった！アドベントカレンダーをキッカケに開催が実現した Redash Meetup を振り返りたいと思う．

qiita.com

既に id:ariarijp から KPT をまとめた記事も出ていて，合わせて読んでもらえると！

ariarijp.hatenablog.com

Redash Meetup

12/19 に Redash Meetup #0 を開催し，ハンズオンイベントとして講師を担当させてもらった．なお，今後 Redash Meetup ではハンズオンイベントだけではなく，実践的な勉強会なども開催する予定がある．

redash-meetup.connpass.com

ハンズオンイベントでは，既にアドベントカレンダーでも紹介した「Redash ハンズオン資料」を使った．基本的には独学できるように作っているし，2時間あれば終わるような量になっているので，年末年始に是非試してもらえると！

kakakakakku.hatenablog.com

勉強会を開催することの大変さ

勉強会の開催はほぼ id:ariarijp にお願いするような形になってしまって，本当に頼もしかった．会場を探し，日程を調整し，キャンセルを考慮して人数を決め，当日のスケジュールを考え，とにかく考えることばかりだった．開催に必要なタスクは全て Trello で管理し，完了の定義も決めて，毎日何かしらの進捗があるように進めていた．

なお，connpass では「イベント統計」を見ることができる．イベントを公開した日にキャンセル待ちになり，翌日には定員の2倍の申し込みになっていた．ここまで人気になるとは予想できてなく，ハンズオンイベントの需要の高さを感じることができた．

f:id:kakku22:20171225010541p:plain

ハンズオンを振り返る

資料

speakerdeck.com

ハンズオンスタイル

ハンズオンとは言え，参加者によってスキルレベルが異なることを予想していたため，全体でペースを合わせながら進めるのではなく，基本的にはもくもく進めてもらうスタイルを選んだ．これは大正解だったと思う．また10名の参加者を2テーブルに分散させ，僕が担当するテーブルと id:ariarijp が担当するテーブルに分けた．その結果，ハンズオンの質問だけではなく，運用 Tips，会社での活用方法など，様々な話をすることができた点も良かった．

ハンズオン当日にバタバタしたこと

ハンズオン資料では Redash を Docker Compose で起動できるようにしていて，さらに Docker For Mac と Docker For Windows での動作確認もしたため，問題ないだろうと考えていたけど，Windows 10 Home + Docker Toolbox という環境があったり，クラウド環境上の Ubuntu + Docker という環境があったり，謎のエラーで起動に失敗する Docker があったりした．その場で対応をしてハンズオンに大きな影響はなかったけど，参加者は「構築方法」ではなく「操作方法」を学びに来ているため，究極的には「構築済の Redash インスタンス」を構築しておいて，すぐに始められる形が良いのかもしれないなと感じた．また，もしものために個人用の Mac を2台用意しておいたので，どうしても環境構築に失敗する人に使ってもらうことができた．これはリスクとして考えておいて本当に良かった．

ハンズオン中に多くあった質問

create_db でエラーが出る

Docker Compose で create_db を実行するとエラーが出る場合がある．これは複数のコンテナ間で起動順序を意識していないために起きるもので，具体的には PostgreSQL の起動を待つと解消する．既にプルリクも出ているけど，現時点では Merge されていないため，ここに関しては「気にせず，もう1度実行しましょう」という回答をした．

github.com

ダッシュボードにウィジェットを追加するときにグラフ名が補完されない

ダッシュボードにウィジェットを追加するときに，グラフ名が補完されないという質問があり，僕のテーブルではほぼ全員から聞かれた気がする．Redash の実装では「最低3文字」を入力しないと補完されないようになっていて，例えば「国の一」まで入れると補完される．グラフ数が多い場合を考慮してだとは思うけど，別に1文字で補完しても良いと思うんだけどなぁー．ここも「今回はグラフ名を全て入力してしまいましょう」という回答をした．ちなみに add-widget-dialog.js に実装がある．

this.searchQueries = (term) => {
  if (!term || term.length < 3) {
    return;
  }

  Query.search({ q: term }, (results) => {
    this.queries = results;
  });
};

f:id:kakku22:20171225010604p:plain

自由演習 + α

ハンズオンだけでは時間が余ってしまう可能性もあったため，事前に自由演習を用意しておいた．しかし，実際には自由演習も終わってしまう人もいたため，追加で Redash 運用のコツなどを話した．

  • 自由演習 1
    • 円グラフの作成
    • 棒グラフの作成
    • ダッシュボードの作成
  • 自由演習 2
    • Redash 内部の PostgreSQL に接続するデータソースを追加
    • クエリ全件を取得するクエリの作成
    • イベント件数を時系列に表示するグラフの作成
  • 追加演習
    • 一般ユーザー登録をして，アクセス制御の確認をした
    • 管理者専用画面 (/admin) の解説
    • システムステータス画面 (/admin/status) の解説
    • Google Spreadsheets 連携の解説

次回開催

1月末に再演予定！お楽しみに！

レポート記事

tech-progrhyme.hatenablog.com

qiita.com

Fargate を試した感想と ecs-deploy で Fargate にデプロイできるようにする話

ECS AWS

f:id:kakku22:20171223125406p:plain

今日は「AWS Fargate Advent Calendar 2017」23日目の記事として，Fargate を試した感想と，デプロイツールの ecs-deploy で Fargate にデプロイできるようにする話を書いてみたいと思う．アドベントカレンダーの記事はどれも本当に素晴らしくて，Fargate 最高！という空気感が伝わってくる．東京リージョンでも使いたいなぁー！

qiita.com

今までの ECS を振り返る

既に本番環境で複数の ECS クラスタを運用していて，スケーラビリティ／運用のしやすさ／可搬性など，様々なメリットは感じているけど，やはりコンテナインスタンスを意識して設計する必要があった．

例えば，デプロイ戦略で言えば Minimum Healthy Percent と Maximum Percent を考える必要があり，デプロイ時に Desired Count のキャパシティをどの程度維持するかを考える．例えば Maximum Percent を 200% にする場合は，一時的に Desired Count の2倍までスケールするため，そのリソースを配置できるコンテナインスタンスを用意する必要がある．実際にはそこまで厳格に計算せず，余裕を持ったコンテナインスタンスを稼働させていることが多かった．

また，ECS でオートスケーリングを実現する場合，コンテナインスタンスに対する「オートスケーリング」と，タスクに対する「サービスオートスケーリング」を気にする必要がある．以下のように設定して運用していたりもするけど，実際に負荷テストをしてみると，データストア側が詰まって別のボトルネックが見つかったり，アーキテクチャ的に別のトリガーでオートスケーリングをした方が適切な場面もあったりした．このあたりはじっくり考える必要があり，AWS に詳しくないメンバーに「難しい...」と言われたこともあった．

  • 例 :「オートスケーリング」の場合
    • ECS クラスタの CPUReservation を監視して，クラスタ全体の CPU ユニットの量でスケールさせる
  • 例 :「サービスオートスケーリング」の場合
    • ECS クラスタの中に複数のサービスを乗せることもあるため，サービス全体の CPUUtilization を監視して，タスクをスケールさせる

docs.aws.amazon.com

また，コンテナ内部のモニタリングをする方法も悩んだ．他のチームが積極的に Datadog に乗り換えていく中，Mackerel でモニタリングをしようと試みていて，完全にワークアラウンドのような仕組みだけど，問題なく動くようになり，今もこの仕組みを使っている．けど，コンテナインスタンスに Mackerel Agent をインストールするため，今後コンテナ部分はやはり Datadog への移行を検討するかもしれない．

kakakakakku.hatenablog.com

Fargate に対する期待と試した感想

このような現在の背景を考えると，コンテナインスタンスの管理をせず，コンテナにフォーカスして運用できるというのは非常にメリットになる．オートスケーリングの面でも，サービスオートスケーリングのことだけを考えれば良くなるのも嬉しい．現在は us-east-1 でしか使えないけど，さっそく Fargate を試した．既に詳しい記事がたくさん上がっているけど，自分のメモを兼ねて書いてみる．なお，Fargate の紹介記事は公式からも出ている．

aws.amazon.com

cpu / memory

今までの ECS だと任意設定だったタスク定義の cpu / memory が Fargate では必須になる違いがある．また，自由に設定できず，決まった組み合わせの中から選ぶ形になる．詳しくはドキュメントに書いてあるけど，このあたりの変更点は頭に入れておいた方が良さそうだなと思った．

  • 256 (.25 vCPU) - Available memory values: 512MB, 1GB, 2GB
  • 512 (.5 vCPU) - Available memory values: 1GB, 2GB, 3GB, 4GB
  • 1024 (1 vCPU) - Available memory values: 2GB, 3GB, 4GB, 5GB, 6GB, 7GB, 8GB
  • 2048 (2 vCPU) - Available memory values: Between 4GB and 16GB in 1GB increments
  • 4096 (4 vCPU) - Available memory values: Between 8GB and 30GB in 1GB increments

docs.aws.amazon.com

ネットワークモード awsvpc

今までの ECS だと，ネットワークモードはデフォルトの bridge を使っていて，コンテナインスタンスと同じネットワークで外部にアクセスするような構成になっていたけど，Fargate では awsvpc が必須となる．awsvpc ネットワークモードというのは，コンテナ自体が ENI を持って，自律的に外部にアクセスできるようになる構成で，以下の記事で詳しく解説されている．Fargate では，コンテナインスタンスを意識しないため，当然ネットワークの部分を考慮する必要があり，それがコンテナのレイヤーに上がってきたというイメージになる．合わせて，セキュリティグループもコンテナに付けられるようになるというメリットもある．ただし，ENI を持つということは，サブネットの IP が枯渇する可能性があり，そのあたりは VPC 設計からやり直さないとダメな場合もありそう．

aws.amazon.com

Auto-assign public IP

Fargate というか，ネットワークモード awsvpc の場合は，コンテナにパブリック IP を設定することもできる．ECS サービスを作成するときに Auto-assign public IP の設定を選ぶことができる．試しに Enabled にして起動してみると，ALB のターゲットグループでパブリック IP が設定されていることを確認できた．もしくは NAT Gateway を経由して外部ネットワークにアクセスすることもできる．なお，Fargate ではターゲットグループの接続タイプが instance から ip に変わるので，ここもちゃんと理解しておく必要がある．

f:id:kakku22:20171223132116p:plain

課金体系

Fargate の課金体系は「使っただけ」となり，以下の簡単な計算式になっている．あまりリクエスト数が多くなく，処理速度も早ければ，コスト削減に繋がると思うけど，逆にコンテナインスタンスを上げっぱなしにしておいた方がコスト削減になるパターンもあるとは思う．とは言え，コンテナインスタンスの運用コストを考慮すると，やはり Fargate の方が良いなと思うし，そもそもコスト削減を目的に Fargate に移行することはあまりなさそう．それなら SpotFleet で高めに買っても全然コスト削減になるような気がする．

Price per vCPU is $0.00001406 per second ($0.0506 per hour) and per GB memory is $0.00000353 per second ($0.0127 per hour).

aws.amazon.com

アドベントカレンダーでも，課金体系にフォーカスした記事があり，非常に参考になった．

qiita.com

ecs-deploy の Fargate 対応

さて，やっと本題に入る．ECS のデプロイツールはいろいろと乱立していて，CloudFormation や ecs-cli や ecs-deploy がある．僕が運用している環境では ecs-deploy を採用しているので，定期的に GitHub をウォッチしているんだけど，re:Invent の直後に「Fargate 対応よろしく！」という Issue が出ていて，そのまま放置されていたので，これに挑戦することにした．

github.com

確かに，master ブランチにある ecs-deploy で実行したら，以下のエラーが出た．

An error occurred (InvalidParameterException) when calling the UpdateService operation: Task definition does not support launch_type FARGATE.

タスク定義の差分を調べる

ecs-deploy の仕組み上，タスク定義の JSON を jq でゴニョゴニョする感じになっているため，まずはタスク定義の差分を調べることにした．アドベントカレンダーの中に Terraform を使って定義の差分を紐解く記事があり，この記事がとにかく参考になった．実際にタスク定義の JSON を比較してみたら，確かにその通りの差分を確認することができた．

hoshinotsuyoshi.com

主な差分は executionRoleArn / requiresCompatibilities / networkMode / memory / cpu あたりになる．

{
  "executionRoleArn": "arn:aws:iam::111111111111:role/ecsTaskExecutionRole",
  "containerDefinitions": [
    {
      （中略）
    }
  ],
  "placementConstraints": [],
  "memory": "512",
  "compatibilities": [
    "EC2",
    "FARGATE"
  ],
  （中略）
  "requiresCompatibilities": [
    "FARGATE"
  ],
  "networkMode": "awsvpc",
  "cpu": "256",
  （中略）
}

ecs-deploy の createNewTaskDefJson() を修正する

あとは jq でゴニョゴニョするだけなので，タスク定義の requiresCompatibilities の値で Fargate 判定をして，Fargate の場合，必要なパラメータを追加でフィルタするとうまく動くようになる．さらに従来のタスク定義には requiresCompatibilities のキーが存在しない場合があるらしく，jq の select を使って対応した．プルリクも出したけど，一部の環境でエラーになるとレポートがあり（ただし僕の環境だと再現しない），まだ Merge してもらうところまでは進められてない．

github.com

実行イメージ

特に Fargete 用のオプションなどは必要なく，タスク定義から自動判定されるので，今まで通りのコマンドで実行できる．

$ ./ecs-deploy --region us-east-1 --cluster my-fargate-cluster --service-name my-fargate-service --image 111111111111.dkr.ecr.ap-northeast-1.amazonaws.com/goapi:10
New task definition: arn:aws:ecs:us-east-1:111111111111:task-definition/goapi:10
Service updated successfully, new task definition running.
Waiting for service deployment to complete...
Service deployment successful.

まとめ

  • 今までの ECS を振り返った
  • Fargate を実際に試して，ポイントとなる仕様などを調べた
  • デプロイツールの ecs-deploy で Fargete にデプロイできるようにプルリクを送った

github.com

Black Belt

www.slideshare.net

アウトプット駆動学習を習慣化する

勉強会

今日は NTT コミュニケーションズ様の社内勉強会 TechLunch にご招待頂き，「アウトプット駆動学習」をテーマに登壇をしてきた．ランチタイムに開催するというカジュアルなスタイルで，参加者も多く，とにかく活気があった．素晴らしい勉強会にご招待頂いた @iwashi86 さんに感謝！ありがとうございました．

発表資料

ストーリー

今回のストーリーは，11月に公開した「ブログを書く技術」をベースにしている．さらに話を広げて「アウトプット駆動学習をするとどんなメリットがあるのか？」と「どのように習慣化をしているのか？」をメインで話した．Trello を使うコツだったり，スプリントをどのように進めているかという話は，今まであまり話したことがなかったため，気になっている人はいるかもしれない．

kakakakakku.hatenablog.com

質疑応答

「どんなクオリティでアウトプットすれば良いか？」という質問が多く，確かに難しいし，気になるポイントではあるなと感じた．最終的には感覚的な判断になってしまうとは思うけど，今回僕は「例えば実装中にエラーが出た場合，そのエラーメッセージ全部と，解決方法が載っている GitHub Issue の URL を載せて，少し補足コメントを書けば十分価値があるのではないか？」と答えた．実際に実装中にエラーが出た場合，エラーメッセージを検索し，上位に出た記事を経由して GitHub Issue を発見するケースは多いと思う．また，アウトプットに慣れてくれば，独自のクオリティ基準が作れてくると思う．

ただし，今回は「習慣化する」ことを話した背景もあり，「クオリティを気にしすぎてアウトプットできない」のであれば「最低限のクオリティでもアウトプットするべき」という点も答えた．

まとめ

  • TechLunch は素晴らしい勉強会だった
  • 僕が今まで実践してきた「アウトプット駆動学習」を紹介した
  • 合わせて重要な「習慣化」と「時間管理術」と「スプリント」も紹介した

参考記事

ポモドーロの話は以前書いた記事も参考になるかと！

kakakakakku.hatenablog.com

紹介した書籍

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

Amazon

｢1日30分｣を続けなさい！Kindle版: 人生勝利の勉強法55

｢1日30分｣を続けなさい！Kindle版: 人生勝利の勉強法55

Amazon

ちょっとした勉強のコツ (PHP文庫)

ちょっとした勉強のコツ (PHP文庫)

Amazon