移転しました。

約3秒後に自動的にリダイレクトします。

YAPC Tokyo 2019に参加してきました。【学生旅費支援枠】

エンジニア成長日記 大学生活 イベント

f:id:kousy:20190130214138j:plain
クロージングの時の写真
yapcjapan.org

圧倒的感謝

学生旅費支援の制度を使わせて頂いて、YAPC Tokyoに行ってきました。 スポンサー企業のGaiax様、GMOペパボ様、Seesaa様、こだまリサーチ様有り難うございました。 学生特権を使えるのは多分、今回が最後になるかと思います。 4月からは社会人としてエンジニアコミュニティに貢献していく所存です。

セッションの感想など

チームが前に進み続けるために僕たちが考えたこと

speakerdeck.com

papixさんの考えたことシリーズの第4弾、スクラム、アジャイル開発を導入してエンジニア兼スクラムマスターを務めた時のお話でした。 toB向けのはてなブログの開発チームにおいて、企画の全貌やタスクの状況が分かりづらく余裕がないという停滞感を感じていたことが有るそうです。 そんな時、解決策の一つとしてスクラムを取り入れて見たそうです。流れとしては、

  1. まずはインプット
  2. チームに周知
  3. 腹をくくる

というものにしたそうです。 新しいことをやる際に自分が徹底的にしっかり勉強するということは、自身としても取り組みたいと思いました。 また、チームに周知することも同じくらいに大事なことですよね。 ここで、同意や共感が得られないと導入後にうまくいかなかったり、そもそも導入できなかったりしそうです。 また腹をくくるというのも重要ですね。 入社後に自分が新しいことを導入することになるとき、この3つのことを意識しようと思います。

具体的な方法はスライドに書かれていると思うので割愛しますが、僕が印象に残った話があります。 タスクをポイント化する見積もりの仕方は、期限の決まっているプロダクト開発において有効であって、期限のない場合は有効ではないという話です。 期限が有るときにユーザーストーリーのポイントに応じて優先順位を決めて、優先度の高いものから取り組んで、そうでないものは諦めていくという方法は有効そうですよね。 期限なく進み続けるスクラムでは、取捨選択を求められることは少なく、時間がかかるので後回しにするというの絶対的見積もりで代替可能だとのことです。 個人開発にも活かせそうな考え方だなと思いました。 最後に、はてなの人々の名言がかっこいいのでご紹介します。

  • "業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています。" - id:Songmu

  • "がんばろう　まだまだわかい　これからだ" - 詠み人知らず

  • "手を動かした者だけが世界を変える" - id:onishi

私とOSS活動とPerl

www.slideshare.net

同じ生命科学系出身からのエンジニアというキャリアの@duck8823さんのOSSに関するトークでした。 OSS活動が転職活動に役立ったり、個人プロジェクトを進めて世界に貢献出来ているというお話でした。 ドキュメントの修正を怠らないように、という話が印象に残りました。 確かにドキュメントが整備されてないが為に、調査に時間がかかることってありますよね。

Javaのライブラリの構造を真似て作ったという似たI/Fを持つPerlのライブラリ。 何らかのライブラリを他の言語で書き直すというのは、取っ付きやすそうでいいなと思いました。

github.com

github.com

SlackのRTM(Real Time Messaging)APIを利用したBotを作るためのライブラリ。 github.com

現在Goで開発されているという特別な設定ファイルを必要としないシンプルなCIサーバー。 最近TravisCIを個人開発に導入して、設定ファイルとか面倒だなと思った僕にとっては是非開発が進んでいって欲しいなと思うモノでした。 github.com

Perl to Go

Perlを10年くらい書いていた@xaicronさんがGo言語の紹介、Perlとの相違点などについて述べたトークでした。 Goを書いたことがないPerl Mongerにとってはすごく分かりやすくて親切なトークだったと思います。

ISUCON8予選問題作成の裏側

speakerdeck.com

ISUCON8予選には出場していただけに、一番楽しみにしていたトークでした。

  • 競技成立
  • 楽しさ
  • 解ける
  • 低コスト　

以上の4つの観点から問題を作成していたそうです。 個人的にかるぱさんの定義を考えて、具体から抽象へという話の展開がすごく好きです。 低コストでの言語移植の為に、シェルスクリプト、SQL、フロントエンドに処理を寄せるというのは予想が当たった感じでした。 ISUCONは本当に勉強になりました。 来年も必ず出ようと思います。 問題作成お疲れ様でした。

多くのCPAN Authorに育てられ、息をするようにCPANモジュールを書けるようになり、そして分かったこと

songmu.github.io

songmuさんと言えば、ザ・強い人のように思っていましたが、色々な経験をOSSを通して得るて、ここまで強くなったのだなぁということが分かったトークでした。 長期的な視点でエンジニアとして、コードを書いていこうと思いました。

年末年始だからと言って気合いを入れた投稿をしようなどと思わない方がよかった

大学生活

はじめに

年末年始に気合いを入れた記事を書こうかなと思っていたものの、なんやかんやで遅くなってしまいました。 目標の立て方とかエンジニアのキャリアについて、色々とインプットをしていたらエディタとメモ帳(物理)の中に知見が溜まって満足してしまう結果になりました。 気が向いたら書きます。 取り急ぎ、目標の振り返りと設定を。

12月の目標の振り返り

  • 卒論提出
  • Railsガイドの写経を終わらせる（入社前課題）
  • Goで開発しているアプリを完成させる
  • Courseraの機械学習コースを4週目までは終わらせる
  • 家の大掃除やバイトの引き継ぎなどの年内に片付けるべきこと

Goで開発しているアプリはデプロイまでの方法が見えず、ガウディって（永遠に完成しない状態を指す）しまってます。 機械学習のコースについても同様。 その代わりと言っては何ですが、Railsでアプリを作ってHerokuにデプロイというのを2回やりました。 完成させるとスッキリしますね。 今後テストを書いたりCIを導入したりして学びに活かしていこうと思います。

1月の目標(だったもの)

  • 実験に着手
  • 卒論発表のポスター完成
  • 卒論再提出
  • 卒論要旨提出
  • 「初めての自動テスト」読了（入社前課題）

初めての自動テスト ―Webシステムのための自動テスト基礎

初めての自動テスト ―Webシステムのための自動テスト基礎

まとめ

相変わらず卒論に結構作業量が求められるので、プログラミングにフルコミットできない日々です。 短いですが、今回は以上です。 次回の記事はYAPC Tokyo 2019に行ってきた！の予定です。

月はじめ、週はじめに目標管理をしている話

考えたこと

読んでくださっている皆さんありがとうございます、どうもコーシーです。

僕は月はじめの1日と週はじめの月曜日を大事にしています。 一日の中でも、朝の作業始めの時間を大事にしています。 その時間でタスク管理というか、やることや目標をなんとなく決めています。 紙の小さい手帳を持っていて、タスクを書き出して終わったら消すというシンプルなやり方です。

11月の目標

11月の僕の5つの目標を晒してみます。

  1. 実験手法の勉強
  2. 卒論に着手する
  3. プロを目指す人のためのRuby入門の写経を終わらせる（入社前課題）
  4. 新しい技術の勉強に着手(Go/Scala/機械学習)
  5. ジムで筋トレ

一応優先順位順になっているんですが、1と5を達成出来てないというの何とも言い難いですね、、、。 実験手法の勉強に関しては着手はしたのですが、他のラボメンバーとの日程調整もあり完了には至ってないんですよね。 チェリー本の写経は入社前課題として取り組んでいたのですが、以前に読んだことがある本でした。しかし、450ページの量ををただ読んでインプットするのと写経して実行して考えながら読むのでは全然学習効果が違いました。 チェリー本についてはまた別記事で書こうと思います。 ある程度Rubyに自信がついた気がします。

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)

Goに関しては仮想通貨のシステムトレードのアプリを開発しています。ガウディらせず完成させたい。 ScalaはN予備校の教材で軽く触ったのですが、言語仕様が気に入ったので今度も時間が空いたら勉強していきたいですね。 機械学習に関しては、CourseraのAndrew先生の講座で勉強しています。機械学習って統計じゃんと思ったけど、前者はデータの予測後者はデータの説明に重きを置いているという説明にすごく納得いきました。 また、「ジムで筋トレ」というのは筋トレをするという意味ではなく、近所の24時間使えるジムに入会して、早朝の筋トレを習慣にするという意味なのですが、月初に動かなかったせいで1ヶ月先送りになってしまいました。入会手続きは済ませたので、今日から通います。 筋トレは正直好きではないんですが、得られるメリットがあまりにも大きいので多少お金をかけてもやっていこうという感じです。 最新の論文を噛み砕いて紹介して下さるこのブログ↓が好きで、よく読んでいます。

www.rehabilimemo.com

12月の目標

そして12月の目標です。

  1. 卒論提出
  2. Railsガイドの写経を終わらせる（入社前課題）
  3. Goで開発しているアプリを完成させる
  4. Courseraの機械学習コースを4週目までは終わらせる
  5. 家の大掃除やバイトの引き継ぎなどの年内に片付けるべきこと

12月前半は卒論メインで後半からその他のことを腰を据えて取り組んでいこうかな、という感じです。 しっかり色々終わらせて、心置きなく忘年会を楽しもうと思います。 それでは！

Go Conference 2018 Tokyoに行ってきた【Wantedlyスカラシッププログラム】

イベント

f:id:kousy:20181125235125j:plain

www.wantedly.com

参加の経緯など

Wantedly社のスカラシップ(交通費、宿泊費)でGoogle Tokyoオフィスで開催されたGoConに参加してきました。 Twitterでスカラシップあるよ!というツイートを見かけたのがきっかけでした。

Go言語は最近個人開発で触り始めたばかりなので、このプログラムがなかったら絶対に参加していなかっただろうと思います。 Wantedlyさん、ありがとうございました。

応募フォームにはGo言語での開発経験を書く欄があったのですが、最近書き始めたばかりで経験が浅いので駄目元の軽い気持ちで応募しました。 Goのこと以外は3社でのインターンの経験を応募フォームに書きました。 沖縄という東京からかなり遠いところからの応募だったので選ばれやすかったのかな、と思います。

当日レポート

いくつかのセッションについてレポートを書きます。

Microservices実践ガイド

メルカリではどのようにMicroservicesを実装しているかというテーマのお話でした。 メルカリ本体はもともとPHPのモノリシックAPIだったそうです。 開発チームのスケーラビリティやデプロイ回数の増加と言った組織的課題に立ち向かうためにマイクロサービス移行することになったそうです（最近何回か聞いていた）。

作る流れ: Protocol Buffersの定義 => サービス実装

Protocol BuffersはJSONのようなスキーマ言語だそうです。 gRPCにおけるインターフェース定義に使用できるようになっており、 全サービスのprotoファイルを集約するリポジトリを作っているそうです。 開発者がProtocol Buffersを作成し、git pushすると Circle CIが言語のクライアントやサーバを自動生成。 全てのメンバーはProtocol Buffersファイルを読めば、APIのインターフェースを理解できるので、他チームのサービスの詳細を知らなくていいようになっている。という感じでした。 サービス実装の流れは以下のようになっているそうです。

  1. テンプレートプロジェクトをcloneして名前つける
  2. rm -rf .git
  3. git init
  4. サービスを作る!!

Goを使ってみてわかるいいところ

静的解析できる。 golintやgoformatで書き方統一できる。 シングルバイナリで動く。 ハイパフォーマンスかつチューニングしやすい(並列実行)。 ネットワークレイヤのコードが書きやすい。 ミドルウェア作るのに適している。 よく言われていることですが、メルカリほどのサービスが実際に運用した結果で述べているので説得力あるなぁと思いました。 将来はチームごとに技術スタックを選択できるようにしたいとおっしゃっていました。

よくあるJava IT企業で新規プロジェクトをGoで立ち上げてみてる話

Goでバリバリ開発をしている!という訳ではない企業のお話でした。

  • 自社でGo使いたいけどまだ導入できてない人向け
  • JavaをGoで置き換えたい、世界中で使われてほしい
  • 電子コンテンツのマネジメントをしている(出版社とkindke,LINE漫画の間に入るお仕事)

Golang導入の軌跡

きっかけはコンテンツの配信エンジンの置き換えをしようとしたそうです。 そこで以下のような問題点が挙げられていました。

  • 現状のJava実装では機能追加、不具合修正が難しい
  • フレームワークなしのほぼ全て自前での実装で
  • 10年前と変わらない技術スタック

単にGoを導入したいだけではなく、ビジネスとして成り立つサービスにしたいのと、 今後10年続くサービスにして新しい技術でエンジニアのモチベーションもあげたいという狙いもあったそうです。 また、優先度の高い機能から置き換えようとしら、結果的にMicroservice化もしたそうです。 キーパーソンだけ説得し、まず動くもの見せてるということも言われていました。 これは地味に今後の参考になりそうでした。人を動かすの、大変ですよね。 array, slice, pointerと向き合いすぎないようにしたというのも、初学者には良いと思いました。

気づいたこと

  • build生成物が大きい
  • 過剰なフレームワーク(gRPCとか)は入れない方がいい
  • エラーハンドリングが難しい、ある程度実装して初めてパターン見えてくる

今後

本格的なサービス運用はこれからとのこと。 成熟したコーディングをしていきたいそうです。 成熟したコーディングには僕も激しく同意!という感じです。

OpenCensus による APM の実現と、未来

speakerdeck.com

なぜAppのパフォーマンスを気にする必要があるのか?という問いかけで始まりました。 もちろんその答えはユーザー体験を向上させるためですね。 APM(Application Performance Management)とは、要求されているサービスの質を保つ為に、アプリケーションのパフォーマンスの継続的な監視と管理を行うことだそうです。初めて知りました。その為に必要なことは以下の2つですね。

  1. パフォーマンス改善に必要なデータの取得
  2. 取得したデータを可視化、活用できる基盤の構築

よくある構成でデータを収拾しようとすると、 コードベースと基盤が密に結合してしまいます。。 そこで、Open Census登場です。 OpenCensusとはAPMに必要なデータを収集し、外部サービスに提供するためのフレームワークで、Google社内のCensusと呼ばれうライブラリをOSS化したものです。 これがとても便利なのですが、欠点もあって

  • バックエンドとデータ収集の結合度を下げたことで、バックエンド固有の最適化のためのメタデータの付与ができない。
  • 一般的なuse caseに対する共通化、ライブラリ実装の拡張に対する仕様が必要

とのことでした。

将来的には、

  • コードベースと基盤と依存を極力無くしたAPMの実現が可能になる
  • ベンターに依存しない実装により、APMはさらなるecosystemの成長を遂げるであろう

とのことでした。 後半引用が多くなってしまいましたが、どういうライブラリをいかに使うかで、会社のサービスの質は大きく変わるからエンジニアの責務は大きいなぁと思いました。

Profiling Go Application

speakerdeck.com

Go製のアプリの高速化やプロファイリングの実例を、プロセスを追って説明するというものでした。個人的には一番印象に残ったトークでした! 画像変換サーバー、kubelt、go-swaggerなどのチューニングの話を聞きました。 遅いと思ったら計測してみようというのは当たり前ですが、やっていないことだなぁと気づかされました。 cliならpkg/profileを仕込んでみたり、サーバーならnet/http/pprofを使いましょう。 そして、原因を特定したらbenchmarkを書いて、プルリクを投げましょうという話でした。 Goはチューニングしやすい言語ですが、必要を感じるまでチューニングはしないでおきましょう。でも、チューニングに必要な環境は用意するべきでしょう。という締めでした。 チューニングしてはプルリク投げるってかっこよすぎ! ISUOCNやっていたせいか、チューニングは興味を惹かれました。 (pprofはについては以下の記事が分かりやすかった。)

christina04.hatenablog.com

Consider pluggable CLI tool implementation

speakerdeck.com

grapiとはgRPCサーバのscaffolding tool/template generatorだそうです。 簡単にいうとgRPCとコードジェネレーターが合体したようなものらしい。 GoのAPI Server開発体験を高めるCLI + package。 ユーザが外から拡張できるようにする(extensibilityを高める)為に、plugin機構になっているというのはなるほどと思いました。 体験良いツールの例として、 * Rails Generators * create-react-app Goで実装しやすそうなツールの例として、 * protoc * kubectl * Terraform * SQLBoiler が挙げられていました。 後半4つのツールについては今後調べたいと思います。 中間をすっ飛ばしてしまって申し訳ないのですが、結論が響きました。 メインじゃない機能はpluginとして提供できるようにすることで、OSS burnoutを防止してかつ、継続的にメンテする為にも「ひとつのことをうまくやる」アーキテクチャにしたというのは参考になりました。 git cloneしてすぐに使えるツールって素晴らしいですし、それが継続的にメンテされるなんて最高ですよね。

フィードバック制御によるGoroutine起動数の最適化

speakerdeck.com

タイトルの通り並行処理と最適な並行数がテーマでした。 このテーマはISUCONの時のunicorcのworker_processes数をいくつに設定したらいいんだろう？と疑問を持った時から気になっていたことでした。 しかし、処理の特性、ランタイムやスケジューリングの特性を考慮しないといけないので、普遍的なチューニング手法の発見はやはり困難ですよね、、、 しかしCPU負荷に応じて継続的に並行数を最適化できるKaburayaアーキテクチャという物をGo言語に適用したすることで、並行数の増加が性能に影響するタスクにおいては、妥当な並行数を算出できる可能性が示されていました!!すごい!! スライドの作り方が研究発表っぽくて好きでした。笑 もっと理解できるように制御工学勉強したいと思いました。 ちなみに紹介されていたバッファ付きチャネルをセマフォとする並行数制御のGo実装のコード。

func main () {
  var wg sync.WaitGroup
  sem := make(chan struct{}, 3)
  for i := 0; i < 10; i++ {
    wg.Add(1)
    sem <- struct{}{}
    go func () {
      defer wg.Done()
      defer func () { <-sem } ()
      task()
    } ()
  }
  wg.Wait()
  close(sem)
}

Pains and gains of architecting microservices on local dev environment

speakerdeck.com

言語が異なることによる開発環境の複雑化

70(諸説あり)のマイクロサービスたちが、動いているWantedlyのサービス。 そんな、ローカル開発環境ってミドルウェア、システムライブラリなどのせいで複雑になりますよね。 開発環境をDocker化することで解決！ってのは最近よく聞きます。 そんな中で、rid-(run in docker)、というツールをGoで開発されたそうです。 ridをインストールしてコマンドを実行すると、コンテナの中でrailsのbundle installやrails db:createやrails serverが実行されて環境依存の問題を無くせるみたいな感じの話でした。

複数サービス間通信時のサービスディスカバリ

複数箇所で同時多発にマイクロサービスが立ち上がってしまうと、ポートの取り合いが発生してしまうそうです。 これもridで解決してくかもしれないという感じの話だったと思います。 制限時間と自分の集中力の関係で、曖昧な感じです。 もっとサービス運用した経験を持ってこういう話聞きたいなー!!と思いました。

GoCon反省会兼RejectConあるらしいので、知りたい方はこちらへどうぞ!

wantedly.connpass.com

感想

カンファレンス以外のことも書いておくと、Airbnbで取って頂いた宿に学生4人で泊まったり(常時もくもく会していた)、 Wantedlyの方々とフィンランド料理をランチに食べに行ったり、ステーキ屋さんに連れて行ってもらったりと楽しい時間を過ごせました。 オフィスは緑に囲まれた立地で内装も良くて気持ちよく仕事できそうな感じでした。 オフィスの会議室の名前がジョジョのスタンド名になっているような遊び心も良いと思いました。 こんな感じで締めようと思います。 Go言語もっと書いていくぞ! Wantedlyの皆さん、貴重な機会をありがとうございました!!

ブログにGithubの草とOsushiを設置した話

考えたこと

PCから見ていただければ分かるんですが、このブログのサイドバーにGithubの草とOsushiというサービスのボタンを設置しました。

草

最近Pixelaで話題になったid:a-knowさんが開発されたGrass-Graphというサービスを使っていて、 Grass-Graph / Imaging your GitHub Contributions Graph

はてなブログへの設置にはid:Junichiitoさんの記事を参考にさせて頂きました。 blog.jnito.com

縦長なのが気になったので、以下のimgタグのrotate=90を消してあります。

<div class="github-link">
  <i class="fab fa-github-square"></i>
  <a href="https://github.com/kou-sy" target="_blank">kousy</a>
</div>
<a href="https://github.com/kou-sy" target="_blank">
  <img src="https://grass-graph.moshimo.works/images/kou-sy.png?rotate=90">
</a>

ここ1ヶ月くらいは入社前課題としてプロを目指す人のためのRuby入門をやっていたので、毎日草を生やすことが出来ました。 また、Rubyに対する理解もかなり高くなりました。1つの言語を深く勉強するのも楽しいです。

寿司

こちらはid:nunulkさんがブログに設置されていたのを真似させて頂きました。 投げ銭も出来るし、0円だけど応援のメッセージも送れるという感じのサービスです。 寿司ってところが気に入りました。

nunulk.hatenablog.com

近況

Laravelミートアップに行ってみたり、機械学習をオンラインのコースで学んだりという感じですね。 Go言語も偶に書いていて、仮想通貨のシステムトレードのアプリをなんとか完成させたいところです。 もう11月も半分過ぎましたけど、ソフトウェアエンジニア的に充実した日々を過ごせていると思います。 特に、朝夜勉強する習慣が身についたので色々と捗っています。 もちろん、研究もそこそこにやっています。実験が一段落してから、コミットを減らしましたが。 今年は頑張った!と思えるように、年末に向けてもっと頑張ろうと思います。

忙しかったりストレスを感じたりした日々に考えたこと

考えたこと

最近(10月後半)やっていたこと

自分の研究の進捗報告のためのゼミの準備

7月に日本語で発表したスライドを英語に直していました。 また、新しく行った実験の結果も追加していました。 パワーポイントでスライドを作るのが苦手なので、しんどいです。 どうしても白背景に黒い文字ベタ打ちが最高に見やすいと思う。

自分の研究のための実験及びサンプリング(釣り)

自分のテーマに後輩がつくことになったので、一緒にサンプリングに行ったり研究テーマについて話したりしていました。 ここで非常に困った問題が起こりました。 割と苦労して集めたサンプルの魚たちを培養器(温度や光を制御できる)の中で飼育していたのですが、設定温度が25度から4度になっていて全滅しました。 自分の設定ミス、他人が触ったなどいくつかの可能性がありますが、これは非常に痛かったです。 半日くらい本気で落ち込みました。

研究室のB3歓迎イベントの準備

合宿のような形式でペンションを借りる必要があったので、その準備もやらないといけませんでした。 B4の同期4人と準備していたのですが、皆それぞれ自分の発表や予定がある中だったので大変でした。 自分は例のサンプル全滅の件の対応に追われたので、前日の準備にはあまり手伝えず、、、。 そして、当日も料理や片付けなどのために働いていました。 発表をするB4が準備も担当なのは負担が大きい。

論文ゼミのためのサーベイ及び論文読み

11月7日に論文ゼミがあるので、そのために論文を探したり後輩のための論文を探したりしていました。 集中していないと、どんどん時間が過ぎていってしまうのでサーベイにも厳しく時間制限をつけようと思いました。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

論文ゼミ

↑まで書いたところで2週間くらい放置していました。 無事ゼミは終えて、学生最後のパワポ発表が終わりました。 ものすごく出来がよかったという訳でもなく、無難に終わりました。

なぜ忙しかったりストレスを感じたりするのか?

忙しいのはある程度しょうがないですが、ストレスは減らしたいものですよね。 大抵のストレスは人間関係で、後は肩こりや目の疲れなど自分の肉体的なものな気がします。 他者との関わりというのは本当に難しいです。他者の会話や行動をいちいち理解しようとすると物凄く疲れます。 一切他人ことは気にせず、自分勝手に振る舞えれば相当に楽だと思いますが、気になってしまうものやどうしても他の人に介入されることってありますよね。

対策

自分の場合は完全に朝にやる気が高くて、ランチ後に少し下がって(ここで外出)、夕方になると早く帰りたくなって、夜になるとまた作業が捗るというリズムがあります。 変に深夜まで作業したり徹夜したりするのではなく、さっさと寝て先述した良いリズムに乗って、軽く運動したり美味しいものを食べたりする余裕をきちんとキープしていくに限ります。 対人のストレスは色々と省略しますが、多少人に嫌われてもしょうがない！と割り切って自分の大きな目標のために行動していくことで解消しました。

それでは、今日はこんなところで。 11月は新しい技術の勉強会にたくさん行くので楽しく過ごせそうです。

技術書の写経を始めたのでやり方を書いておく

考えたこと

入社前課題として技術書の写経を始めました。 基本的にはこれをマネしています。 しかし、実際にやってみて僕がやり方を変えたところがありますので書いておきます。

1.ローカルで使える SCM を用意

これは普通にgitとGithubでやっています。

2.「ほんたった」などで対象の本を固定 。しかし、電子書籍とか画面で見られるものの方が便利。

僕はこれを使っています。Amazonで安かったので。ページをめくりにくいのと場所を取るので他のものを現在探し中。 物理本はどうしても、PCの横とかに置くことになるんで首や目を移動するたびに疲れる気がします。

actto BST-02BK ブックスタンド

actto BST-02BK ブックスタンド

3.ひたすらサンプルコードを写して実行

基本的にはほとんど実行しています。完璧に分かっているものは、飛ばしています。 プロを目指す人のためのRuby入門をやっているのですが、エディタはやはりRubyMineがいいですね。 補完機能が充実しています。RubyMine上のターミナルから日本語を入力するときに、文字が正しく表示されないのが気になる。

4.実行するたびにコミット(コミットログにページ番号を含める)

大体実行するたびにコミットしていますが、いくつかまとめてコミットするときもあります。 疑問点やなにか書きたいことがあったときにコミットする感じです。 git addやgit commitを何度も打つことになるので、エイリアスを設定しておきましょう。

qiita.com

5.疑問点があったらコミットログや本に書き込む

今は物理本を写経していますが、基本コミットメッセージに書きます。

6.章ごとにディレクトリを分ける

第1章だったら、Section1。第2章だったら、Section2とディレクトリを分けたほうがわかりやすいかなーと思っています。

追記(19/08/21)

章ごとにブランチを切って、その章の最後まで写経したらpushして、プルリクエストを作成してコードにコメントをつけて復習が出来たらmasterブランチにマージしていくというやり方がオススメです。 学生時代に1人でプログラミングを学んでいた時は、プルリクを使う機会が全然なかったのでGitに不慣れでした。こういうときにプルリクを使っておくといいと思います。

写経はいいぞ

僕は読んでいるうちに頭が働かなくなることがあるので、写経で手を動かす方が合っていると思いました。 打って実行すると、強制的に頭が働く気がします。 写経は意味ないぞという意見の人もいるのかもしれませんが、しっかり読んで理解できればどちらもでもいいのかなーと思います。 読んだことのある本でも新しい発見があるので面白いです。 それでは、引き続きやっていきます。