nariのエンジニアリング備忘録

SRE/Devops/AWS/自動化/IaC/Terraform/Go/DDD など

2020の振り返り/2021の抱負

はじめに

こんにちは。都内でエンジニアをしている nariです。

去年に引き続き、今年2020の振り返りをして行こうかなと思います。

一言で言って仕舞えば、withコロナでのリモート生活(3月から一度も出社していない)のリズムが掴めず、最後の最後に掴みはじめた順応/準備の一年だったという感じですね。

全然成果が当初の期待値には達してないですが、向き合い来年の糧にするためにつらつら書いて行こうと思います。

↓去年の記事

fukubaka0825.hatenablog.com

時系列で振り返る

1月

SRE NEXT開催したり、転職活動したり、業務ではUSプロジェクトの進行したりIaC推進したりしてました。

特にSRE NEXTでは様々な人から多くのものを学べたり転職の転機になったり、自分の人生全体でもとても大きな出来事となりました。

2月

私のweb系への転職のきっかけとなったしがないラジオに出演し、web転職から今楽しく働けているのはお二人のおかげですという話ができた。

話し足りなかったしSRE担ってからの話もしたいのでまた遊びに行きたい。

3,4月

Web developer -> SREへのロールチェンジ。

転職。Pairsが好きだったのでマジ嬉しかった。お金も結構上がった。そこらへんの生々しい話が聞きたい人は密をさけながら飲みに行きましょう。

www.wantedly.com

5月

SRE Lounge、初のオンライン開催をしました。

初のファシリと全体コーディネイターをやりました。結構念入りに計画して様々なメンバーにサポートしてもらい、及第点の出来にはできたと思います。

しかしもともとこの勉強会自体において懇親会でのコネクションが非常に重要な要素だったので、これはちょっとオンラインになってからはやり方をがらっとかえんと運営のモチベーションも保てないなと思いました。案の定これっきり2020の開催はなし。

6,7,8月

仕事以外生産的なことは何かした記憶がない。体がずっと重かった。

去年から引き続きニューヨークを筆頭にしぬほどお笑い芸人のYouTubeとアニメや漫画をみていました。後加藤純一の配信。生きる希望。

今年みて一番よかったアニメは映画だけどリズと青い鳥、漫画はぶっちぎりでチェンソーマン。

9,10,11月

1年半くらいすんでいたギークハウス新宿からgoodroomのホテルパスを使ってワーケーション勢になりました。

www.goodrooms.jp

温泉入り放題のホテルがあったり。しかもGOTOでほぼ半額で止まれたりしました。最高。これにかこつけて京都行ったり福岡いったりしました。

最近は新宿にべったり。由縁という宿が雰囲気含め最高です。

来年は北海道に長期滞在しようかなとぼんやり考えてます。

12月

Oculus Quest 2をなんとなく買って、Vの民になりました。これが大当たり。

Amazon.co.jp: Oculus Quest 2—完全ワイヤレスのオールインワンVRヘッドセット—64GB: ゲーム

fitxrというソフトで運動不足解消 and 自律神経も安定。VR Fitness最強。 VRChatの表現からクリエイティブの力の吸収。活力を取り戻しました。

カテゴリー別に振り返る

業務

基本Go/Terraformかいてプロセス全体の最適化(主にSelf-Service化だったり、Infra Develiry Process刷新だったり)をがんばった。

そのほかにもPairs Engage基盤fargate移行、AWS ECR vulnerability scan and workflow作成、BotOps徹底、ポストモーテムTemplate/PlayBook(RunBook)導入したり障害対応システム復旧したり結構色々やった。ほかにやりたいことも無限にあるので切実に仲間を求めている。。

求人の詳細は以下の記事の終わりを参照。

medium.com

去年までの自分なら全てのタスクにアウトプットした記事を引用しているはずだが、そこまでの活力が今年はでなかった。。。

Security/Privacyの案件に後半半年くらいはだいぶ張り付いていたので、この観点でのデータへのアプローチはだいぶ勘所を掴んだ感じがある。ここら辺もっと深掘りしていきたい思いがある。 あと検証用のめちゃくちゃSQL書いた。今までで一番SQLを書いたとしかもしれない。

自己学習/対外アウトプット

ブログ/登壇/OSS活動/英語

ブログは５本...(去年は60本)お世辞にも多いとは言えない。

その他も全くと言っていいほど頑張れていないですね。

現在の弊社SRE Teamの状態がとにかく人を取らないといけない状態なので、自分が頑張って人を連れてくることも来年の大きな主眼の一つとなりそうです。

コミュニティ運営

SRE NEXTは大成功でしたが、SRE Loungeに関してはたったの一回の開催という結果になってしまいました。

chaspyさんとも飲みながら話したりしましたが、新たなスタイルを確立して行こうと運営メンバーと話をしています。

定期的な小規模イベント(SRE Loungeなど)、OBSの勉強をしはじめていて、配信を楽しむことで自分のインセンティブにしようと思っています。運営、登壇者のインセンティブ設計は開催しながら練っていく予定。

大規模イベント(SRE NEXTなど)についてはまだ全然自分の中で考えがまとまっていないです。

cloudnative daysさんが面白い試みをしていましたが、そういう試行錯誤の結果を参考にし、小規模イベントを継続開催しながら色々試行して行こうと思っています。

プライベート

健康面

とにかくフルリモートになってから家から出ないし動かない。体はどんどん重くなっていってました。

先述のようにここはVR Fitnessにすくわれた。12月から1日1時間を目安にやるようにしているが、整い方が半端ない。

ホテルパスでいつでも温泉に入れるのもでかい。全人類ホテルパスとOculus Quest買って使ってくれ。

仮想空間での表現との出会い

楽器をやめて、前職のクリエイター支援の会社をやめ、クリエイティブに触れる時間が大幅に減少したので、いつのまにか無意識に活力がゼロになっていた。

フジロックは中止だし、こんなに音楽ライブに行かない年も久々なくらいいけず、かなり乾いていた。

そんなときに、みんなVRChat上でギターリストMiyaviさんのLiveを筆頭にVRChat上でのカオスともとれる各々の斬新な表現に魅了された。音楽liveに関してはビジュアルは現実を超えれるので、課題は音。クラブにいった時の低温に殺される感覚とか、そこらへんの表現をどう組み込むかだと思います。どんどんアーティストがVR空間上でliveしたり表現していく世の中になってほしい。

自分自身のライフスタイルや職業選択の志向性である、時間と空間の制約を受けないという点がクリエイティブに結びついたこの感覚がすごく気持ちがよくてしっくりきたので、来年はもっと追い求めてみたいです。

リアル/仮想空間問わずいろんなものに触発されながら、VRChat上でアバターなりワールドなりちまちま作っていくことで表現欲的に精神安定につながりそうです。

まとめ and 2021の抱負

こう振り返ってみると今年は順応/準備の年でした。お笑い芸人とアニメと漫画に生かされ、ホテルパス(温泉)とVRに救われた一年だった。

あと転職は成功だった、成長産業でデータとトラフィックに溺れられてやりがいもあるし、なにより従業員のスループット最大化を目指してサポートをたくさんしてくれるとてもいい会社です。

12月くらいからようやくアフターコロナのリモート生活のリズムを掴みはじめた(遅い...)のと、忘れかけていたプライベートの充実の重要性を再認識できたので、来年は今年とは違い飛躍の年にできそうです。というかします！

業務、対外活動(登壇、コミュニティ運営、採用etc)、健康管理(ダイエット)、仮想空間での表現をそれぞれ頑張りたいです。後あわよくばお金周りのお勉強と英語も。 業務では特に、意思決定の質と量をもとめられているので、そこを意識しつつアプリ/データレイヤー改善をメインにふかぼっていく年へ。

それぞれ定量的な目標値を宣言したいところですが、無理はせずマイペースにギアを上げていきたいので今年は宣言しないこととします。(自分の中の目安となる目標値はざっくりあるが)

ここまで駄文読んでいただきありがとうございました。それではみなさま良いお年を！

AWS DynamoDB exportとAthena CreateTable/ExecuteQueryを定期的に実行するLambdaでお手軽データ解析基盤を手に入れる

はじめに

お久しぶりです。都内でエンジニアをしている nariです。 年末年始なので今年やったことをつらつら備忘録としてためておきたいと思います。 (これ一個で終わっちゃうかも。ご容赦)

作った動機

ある案件でDynamoDBに対してある程度複雑なクエリで抽出したい要件がでてきました。 しかし

  • そもそも本番Data Storeに解析クエリを投げるのはよくない
  • DQL(DynamoDB Query Language)の表現(unix timeの扱いetc)が貧弱/毎回解析用にIndexをはるのがつらい

ので、お手軽解析環境をStream/Batchの同期タスクをお守りすることなく手に入れたい思いから作成しました。 今回は、ちょうど今年リリースされたしたDynamo export to s3のという神機能を使って作成していきます。

全体像

f:id:st5818129:20201231152615p:plain

サンプルコードは以下

github.com

サンプルコード解説

Terraform側

DynamoDB table/export先のS3 bucket/Athena database/Athena execute result store用のS3 bucketを作成する

# ./terraform/dynamodb.tf

resource "aws_dynamodb_table" "sample" {
  name         = "sample_dynamodb_table"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "id"

  attribute {
    name = "id"
    type = "S"
  }

  attribute {
    name = "name"
    type = "S"
  }

  point_in_time_recovery {
    enabled = true //①
  }
}
  • ① export to s3の機能を使うのにPITRが必須なのでtrueにしておきます
#./terraform/export_s3.tf

resource "aws_s3_bucket" "sample_export" {
  bucket        = "sample-export"
  acl           = "private"
  force_destroy = "false"

  versioning {
    enabled = true
  }

  lifecycle_rule {
    enabled = true
    expiration {
      days = 90 //②
    }
    noncurrent_version_expiration {
      days = 1
    }
  }


  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        kms_master_key_id = "arn:aws:kms:ap-northeast-1:99999999999999:key/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" //③
        sse_algorithm     = "aws:kms"
      }
    }
  }
}


# enforce public access block on bucket
# reapply on next tf apply if disabled
resource "aws_s3_bucket_public_access_block" "sample_export" {
  bucket = aws_s3_bucket.sample_export.bucket

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}
  • ② 個人情報を含む場合、こういったDataLake移行のレイヤーでも、Dataのライフサイクルを最初から意識して解析側やステークホルダーと握って設定するのが吉です。また、Query Resultを保存する S3 bucketにも同様のサイクルや後述する暗号化を適応する必要があることにも注意してください。
  • ③ 暗号化も各会社の基準によるところですが、重要度が高いものに関してはmanaged kms keyで暗号化するのが賢明だと思います。(内部からの漏洩も対策しておく)

Serverless Framework側

DynamoDB exportとAthena CreateTable/ExecuteQueryを実行するLambdaとCloudWatch Eventを作成する

#./conf/sample.yml

sample_dynamodb_table:
  cron:
    rate: rate(30 days)  //④
    enabled: true
  dynamo:
    arn: "arn:aws:dynamodb:ap-northeast-1:99999999999:table/xxxxxxxxxxxxxxxxxxxxxxxx"
  s3:
    name: "sample-bucket"
  kms:
    arn: "arn:aws:kms:ap-northeast-1:99999999999999:key/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
  athena:
    enabled: true
    database_name: "sample-db"
    query_result_output_bucket_name: "sample-result-bucket"
    table_name: "sample-table"
    table_schema: "struct<id:struct<s:string>,name:struct<s:string>>" //⑤
  • ④ ap-northeast-1で1GBあたり$0.114 per GB (20201231時点)なので、頻度はお財布と相談してください
  • ⑤ Dynamo table export データがこのようにネストされた構造をもっているので、Athena(Glue)で表現しようとするとこれだけ複雑になってします。こちらはid,nameをattributeにもつ場合の例。どのtableもこの形式なので参考にしてみてください
# ./src/module/export_handler.go

func (s *exportHandler) Run() error {
    sess := session.Must(session.NewSession())
    dynamoCli, err := NewDynamoCli(sess)
    if err != nil {
        log.Error(err)
        return err
    }
    exportID, err := dynamoCli.ExportToS3(s.Event.DynamoTableArn, s.Event.S3BucketName, s.Event.KmsArn)
    if err != nil {
        log.Error(err)
        return err
    }
    if s.Event.AthenaEnabled {
        athenaCli, err := NewAthenaCli(sess)
        if err != nil {
            log.Error(err)
            return err
        }
        newLocation := fmt.Sprintf("s3://%s/AWSDynamoDB/%s/data/", s.Event.S3BucketName, exportID)
        outputLocation := fmt.Sprintf("s3://%s/output/", s.Event.AthenaQueryResultOutputBucketName)
        //⑥ 
        if err := athenaCli.CreateTableIfNotExists(s.Event.AthenaDatabaseName, s.Event.AthenaTableName, s.Event.AthenaTableSchema, newLocation, outputLocation); err != nil {
            log.Error(err)
            return err
        }
        if err := athenaCli.ChangeLocation(s.Event.AthenaDatabaseName, s.Event.AthenaTableName, newLocation, outputLocation); err != nil {
            log.Error(err)
            return err
        }
    }
    return nil
}
  • ⑥ 初回はCreateTableをして、初回移行は新しくexportしたobject pathでtable locationを変更しにいきます。これによって、同じtable名で、ある程度の鮮度のデータを解析できるようになります。

Athenaでの引き方

  • 以下のようなsqlでコンソールから引けるようになりました。redashとつなげていつでも解析できるようにすることもできます。
SELECT 
    item.id.s as id,
    item.name.s as name
FROM 
    "sample_db"."sample_table"

終わりに

これで、実行間隔分の反映ラグ(1日おきなら、最大1日分の反映ラグが発生してします)が発生するものの、それくらいのデータ鮮度を許容できる場合簡単にDynamoDBをSQLで解析できるようになりました。 皆さんもDynamoDBに検証/解析用のちょっと複雑なクエリを投げたくなったらこういう感じでさくっとAthenaで解析する方向にシフトしてみてください。

参考文献

SRE NEXT 2020を一運営スタッフとして振り返ってみる

f:id:st5818129:20200127002406p:plain

はじめに

こんにちは。都内でWeb Developerをやってる@nariです。

先日2020/01/25に、日本初のSREカンファレンス「SRE NEXT」が開催されました。

sre-next.dev

以下のツイートで、参加者にブログを書くまでがSRE NEXT!!とか自分で煽っておきながらお前(運営スタッフ)が書かないでどうするんだと言う感じなので、やむなしで書いている振り返り記事がこちらになります。 (参加者やスピーカーの皆さん本当に多くの参加レポありがとうございます。コミュニティカンファレンスらしい盛り上がりで最高)

今回は僕が手伝い始めてからカンファレンス当日までを、一運営メンバーとして振り返っていこうと思います。

手伝い始めるきっかけ

【増枠】SRE Lounge #10 - connpass に参加した時に、丁度SRE Lounge運営スタッフ主体でSRE NEXTというカンファレンスの開催決定が宣言されました。 運用改善や基盤への思いがずっと強かったのもあって、これは絶対に手伝いたいという思いが強すぎて気がつくとtwitterで主催者のかつひささん (@katsuhisa__) | Twitterさんに運営やらせてくださいとリプライを送っていました。

そんなこんなで8月くらいからメンバーとしてjoinさせてもらったのですが、振り返ってみると、SREでもない、しかもメンバーに知り合いもいない何処の馬の骨ともわからんやつをよくホイホイと入れたなという感じが凄いですね。katsuhisa氏の肝っ玉よ。。

で、お前は何をやれたの

途中参加の人間、しかも中には誰も知っている人がいない状態の自分がまずやるべきことは、浮いているタスクを自分で見つけてこなしていくことで信頼関係を構築することだと考えました。

手が回っていなかったTwitterなどの広報、チケットサイト、動画コンテンツ準備のタスクをひたすらこなして言ったり、必要な要件や情報を得るためにコアスタッフを捕まえてどんどんコミュニケーションを取っていくことを重視していました。

コミュニティのコアスタッフの経験が一切なかったのとガムシャラにタスクを取りすぎ＋業務の繁忙期という状況になって、チケット公開でちょっとやらかしてkatsuhisaさんにフォローしてもらったり、多々粗相はあったとは思いますがある程度価値は発揮できたし信頼関係も構築できたかなと思っています。

後は、途中で僕の前職の同僚(@Buzz)と先輩(@ogady)を運営メンバー誘って、自分が抱えすぎたタスクをうまく割振れたのも爆発せずに済んだ要因だと考えています。。@Buzzと@ogadyはありがとうね

ここからは、それぞれやってことをトピックごとに少し振り返ります。

イベントチケット/参加者管理

だいたいチケット周りは一人で担当しました。 イベントチケットサイトとして採用したEventbriteのUIやシステムの不安定さには手を焼かれましたが、機能要件は完璧に満たしていたので、まぁサービス選定は間違ってなかったのかなと振り返ってみて思います。 詳しいここら辺の選定/オペレーションの話はどっかでまとめると思います。

一般参加者人数の意思決定に関しましては、とにかく参加者が快適であることを優先しました。後100人くらいにはチケットを売れたかもしれませんが、それで参加者の満足度が下がっては意味がありませんので、そこの意識は常に徹底して経理周りをすべてやっている@ogmさんなどと相談して決定しました。今回はこれでよかったと思っています。

オープニング動画/セッション紹介動画作成取りまとめ/スポンサー動画作成

当初は私がオープニング動画/セッション紹介動画も作ろうと思っていましたが、動画関連のサービスのエンジニアといえど動画制作の経験はありませんでしたので、クオリティの保証ができないということで外部に委託しました。

そこでお願いしたCrevo様並びに担当クリエイターさんには、低予算(初回なのでお金がない)にも関わらず本当によく対応していただきました。本当に感謝！

「セッション紹介動画を毎セッションの前に流す」案に関しては、発表お立ち台のない会場で雰囲気にあわないのではないか？などの意見がありましたが、僕が登壇者だったらテンション上がるし参加者としてもスペシャリティを感じてくれると判断し、作成し流すことに決めました。

こんな無理なお願いにも関わらず、本番は最高の音響オペレーションをしてくれた@okash1n,@Ryoter,@H.M,@sogaoh氏には本当に感謝しても感謝しきれません。こちらにも感謝の意を今一度表させていただきます！

結構動画系は評判良くて嬉しくて懇親会のお酒がめちゃくちゃ美味かったです。

Twitter運用

とにかく参加者の満足度が下がるようなことが起きて欲しくない一心で事前注意を繰り返し共有すること、みんなで盛り上げていこうと言う意識は徹底していました。

注意事項をひたすら繰り返しメールとともに案内する、ここはしつこいくらいの方がいいと判断し徹底して行いました。(会場、受付混雑回避施策のヨガ、チケット譲渡、QRコードの用意の案内、その他注意事項)

また、イベント開催前からイベントの雰囲気作りは始まっていると思っているので、ひたすら#srenextタグで呟いてくれるツイートは捕捉していいねリツイートしてみんなで作るカンファレンスなんだ、と言う意識を共有することは大切にしていました。

課題としてはマーケティング面で、少し絵力のないツイートばかりで、もう少しツイート構成を工夫できればよかったなと思ってます。(まぁ１ヶ月前には売り切れてしまったので、宣伝のプライオリティが落ちたと言うのもあるのですが)

あとはとにかくSRE NEXTでエゴサーチして、参加予定者がどういう所に不満を持っているかをキャッチするのは毎日やってました。そこからサイトの情報の掲載の仕方を変えたり、個別でフォローするCSライクなこともやっていました。(もちろん直接くるDMの対応も)

参加型アンケートをスポンサーブースへの誘導施策として実施

最終的に100人くらいの人に参加いただけたので、ある程度は成功したかな？(段取りの面でめちゃくちゃ反省がありますが、@saitotaq氏に救われましたありがとう。)次回があるなら、もうちょっと凝った誘導施策をやりたいですね、スポンサーのためにも。

リアクションも結構あった。

当日の反省/振り返り

細かい自分のタスクに対するKPTは多々ありますが、そちらは運営内のシートや振り返り会で細かくやりたいと思います。 自分の全体としての大きな問題としては、

  • 初の大きなカンファレンスの運営スタッフ(ボランティアスタッフは何度かやっていますが)かつ臨機応変な動きが必要となる遊撃隊という立ち位置で、度々適切でない問題提起の仕方をしてしまった(感情が丸出し、解決方法の提案とセットではない)

これがすごく反省です。こればっかりは経験値不足でしゃあないって感じですが、ケーススタディ的に色々こういう問題が起きたらどうするかを想定して学んだりはしていけるはずだし、今回で自身も成長しているはずなので次回以降はもっと柔軟に冷静に対応できるようになります。

SRE NEXTの課題とこれから

TLを追っていても肯定的なツイートが多く、イベントとしては大成功だったとは思いますが、こういう時こそ冷静に課題とこれからについて整理したいと思います。

組織の設計、あり方　

第一回ということもあり、良くも悪くも皆何でも屋で、タスクをゴリゴリ進めていくベンチャースタイルの運営方法でした。

しかし、これからの組織やカンファレンス規模拡大を考えると、この体制は再検討しなければならないと思っています。 継続的にひたすら雑多にタスクをこなすことが美となってしまうと、スペシャリティを持った人間のスポット起用といった選択肢が取りづらくなってしまいます。

ですのでコアスタッフという一律の扱いを僕はやめるべきだと思っています。ある程度Roleを明記したりそれに基づいてチーム編成を考えたり、そういった組織設計を次のステップに進む時にまず初めに考えなければならないですね。

まぁしんどい雑用もたくさんあるんで、そこは皆でやっていくしかないのはそれはそうと言うやつですし、仕事じゃないのである程度奉仕の精神に支えられているのは間違い無いので、そこをどう「俺はこんなに仕事しているのになんであいつはやっていないのだ」と言う負の感情に向かわないように仕組みを作るかが重要だなとおもっております。

カンファレンスとしての方向性

国内でどんどんTokyoだけでないコミュニティの発展を後押ししていくことを重視するのか、それともSREconが無視できない国際カンファレンスとして成長させるのか、SREcon Asia/PacificをTokyoに誘致してまずパイプを作ることに注力するのか。色んな選択肢がありメンバーそれぞれの嗜好があると思っています。ここをきちんと定めるのも、組織設計の再検討とともに初めにやるべきだと考えます。

私のこれからのSRE NEXTとの関わり方

僕のこれからのSRE NEXTとの関わり方として、マーケティングやコンテンツの責任者をやっていきたいと思っています。(海外対応のカンファレンスにしていくならそこにも尽力したい)しかしセッション選定に関しましては、僕の現在のエンジニアリング力では一切説得力がないです。

私は現在絶賛SREへ転職活動中で、1月中にはどこにいくかは決めようと思っています。 (決まったら皆様には改めて報告させていただきます。)

新天地で自分のSREとしてのスキルやスペシャリティを磨きつつ、個人でもアメリカの通信大学でCS学んだりLeetCodeひたすら解いたりして根底の力も伸ばしながら僕の目指す理想のSREになっていき、SRE Lounge/NEXTというコミュニティとともに成長しつつ還元していきたいと思ってます。

最後に

本当に参加者やスポンサーの皆様にはお世話になりましたし、おかげさまで素晴らしいイベントになったと思います。ありがとうございました！今後とも前向きに継続検討しておりますので、よろしくお願いします。

売り切れて参加できなかったよ、、と言う人は多くの人が書いていただいている参加レポや、こちらの資料まとめの記事などを参考にしていただくとどんなイベントかわかりやすいと思いますし、良質な情報ばかりだと思います！(後ほど公式からもまとめて共有します) また、全てではないですが、セッション動画公開予定なのでそちら楽しみにしていてください。

また、スタッフ(当日、コア問わず)の皆さんも言わずもがな最高でした。SREらしい柔軟な動きを皆さんができていて、皆さんのおかげで最高のイベントになったと思います！最後にめちゃくちゃCoolなスタッフの全体写真のツイートを貼ってこの記事は終わりにします。(なおこの写真には僕は載ってない笑)

メインフレームを保守するSIerからWeb Developerにジョブチェンジして、もうすぐ１年経つので振り返る

はじめに

こんにちは！都内でWeb Developerをやっているnariと申します。 現在はアーティスト支援系サービスをGo/AWS/Terraformで開発しています。

今年一年の振り返りはさらっとTwitterで済ませてしまおうと#2019年を振り返るハッシュタグに便乗して上記のようなツイートをしてみたところ、案外多くのリアクションをいただけたので別途記事でも書くかということでこの記事を書いております。

また、今年2月から現職にお世話になっていて、来年の1月末で某金融系SIに所属するメインフレームを保守するSIerからWeb系企業の開発者として転職して丸一年経つということで、そちらもまとめて振り返ってしまおうという感じになってます。(雑)

この記事で書かないこと

  • 抽象的なSIとWeb企業の比較談義

ひたすら私具体的にやってきたこと/それをやった理由を棚卸するだけの記事になります。ご了承ください。

なぜ転職したか

  • ビジネスサイド(銀行)、運用部隊(データセンター)との折衝にひたすら工数を取られる当時の状況に疑問を感じ、devopsを体系的に学びたかった
  • 当時PMとしてキャリアを積んでいく路線だったが、設計/実装/運用を知らないものにエンジニアリングのマネジメントはできないと判断し、全てが効率的に学べるのがWeb業界だと感じた
  • 現職はアーティスト支援をメインの思想として掲げており、音楽やカルチャーが大好きで演者としての人生も考えていた自分にマッチした

結果的にアプリ〜インフラ、設計〜運用まで幅広く経験することができており、ジョブチェンジして正解だったなと思っています。

今年一年で何をしてきたか

業務

GoでのAPI開発

とりあえずJava/Rubyを少し書いていたくらいで、Goが何もわからないので、簡単なWebアプリをMVCで作ってそれをClean Architectureにリファクタする中で基本のお作法を覚えました。正直DIだのDIPだのまじ意味ワカンねぇなってなりましたが、色んな文献を読み実装する中で徐々に自分の中に落とし込めた気がします。

qiita.com

OpenAPI仕様管理ツール(Apicurio,Stoplight)を比較検討を導入し、既存のAPI仕様をドキュメント管理ツールでの管理から移行したりもしました。

qiita.com

qiita.com

それからは、メインプロダクト(動画納品サービス)とショップリコメンドシステム(ポイントモール)のAPI開発を通して、実践的なGoの書き方/generater/testの書き方を学んでいきました。また、チームの流れとしてClean ArchitectureでDI可能な方向にリファクタリングしていくなかで、基本的なレイヤードアーキテクチャやデザインパターンも学んでいきました。

AWS上でインフラ全体を設計し、IaC(インフラのコード化)する経験

こちらは、ショップリコメンドシステム(ポイントモール)を構築するにあたって、新規にAWS上にインフラを構築できるということで、先輩と二人でビジネス的な要件に合わせ全体を設計し、TerraformでIaCしながら実装しました。 以下のように、この案件で非常に広範囲のインフラ構築の経験が積めました。

  • http serverをdeployするための基本的なインフラ(VPC, ALB, S3, RDS,Nginx)
  • 急激なアクセス増加に合わせて、低コストでスケールするアプリケーションサーバー(ECS on EC2,ECR, SpotInstance, CloudWatch Event, Lambda)
  • 顧客影響のあるFatalなアラート時は、Slack通知後に電話(Amazon Connect, CloudWatch Event, Lambda, SNS)
  • レスポンスタイムの要求がシビアになっていくことが見込まれていたので、マスターとは別にアプリがやりとりするデータソースとしてRedisを選択し、List/Hash/String(json)型のパフォーマンス計測で比較検討しデータ設計(Elasticache)
  • 親システムとのマスター同期のための非同期ジョブの実行管理(Step Functions)
  • AthenaでもBig Queryでも解析できるログ基盤構築(Fluentd,Kinesis firehose,S3)
  • 仮説検証を高速で行えるようなCI/CDの整備(AWS CodePipeline,Gitops)

もともと「AWS？何それわからん。。IaCなんてよりわからん。。」だったのが短期間でここまで実装し経験を積めたのは、事前にAWS SAAを取得し頭の中に目次を作り、技術書典6でTerraform入門本の名著「Pragmatic terraform on AWS」を購入しプライベートで色々いじっていたのが効いたと思います。

qiita.com

qiita.com

qiita.com

qiita.com

IaC啓蒙

サービスとして、グローバル展開をするということで従来のGUI管理では限界がきているのは目に見えていたので、自身もう上記の案件でノウハウのあったTerraformの勉強会を開催しました。

qiita.com

こちらの具体的なお話は、SRE Advent Calendar 2019の22日目に書いています。

qiita.com

これからも継続して実施していけたらと思っています。

ChatOps導入

チャットツールにインターフェースを集約し、メンバー操作の履歴をシェアするChatOpsの思想が好きで、AWSリソースを操作するのにクレデンシャルに煩わずスラッシュコマンドで呼び出せるSlackBotを作成し、導入したりしました。

speakerdeck.com

共通検索基盤事前調査・設計(Pending)

弊社のアーティストサービスでは、アーティスト/曲/リリースといったデータ検索をネイティブアプリ/Webアプリでももちろんできるのですが、双方精度とレイテンシーに問題がありました。 ですので、Elasticsearch(形態解析とユーザー定義辞書のメンテ)とGo製のAPIで双方の問題を解決するというプロジェクトをやっていましたが、USプロジェクトの方が優先度が高くなりPendingの状態となりました。

qiita.com

AWS上のステージング・開発環境のリソースのIaCとアカウント移行

こちらはterraform Advent Calendar 2019 15日目の方に詳しく書かせていただきましたので、そちらをお読みいただければと思います。

qiita.com

手動デプロイをCD as a serviceに委譲(WIP)

こちらはまだWIPの状況ですが、手動デプロイをCircleCIとGitopsのよるデプロイのコントロールに以降しようとしており、AWS Codeシリーズとの比較検証は大枠の設計は終えています。来年落ち着き次第こちらも記事にしたいと思っています。

USチームとの折衝/調整/会議のファシリテート

もともと英語のReading/Writingはまぁまぁ不自由なくできる方だったのですが、Speaking/Listeningにかなり苦手意識がありました。しかし、ここ三ヶ月ほどUSチームと週一でmeetingしたり定常的にChatでやりとりしたり、プライベートでもシャドーイングやDMM英会話のレッスンを受けたりすることでかなり苦手意識がなくなり、ビジネス上での意思疎通くらいなら不自由なくできるようになってきました。これからも継続して英語力はブラッシュアップしていきます。

技術発信支援

もともと入社当時は弊社のアウトプットはお世辞にも活発な状況とは言えなかったので、まず自身が週一でアウトプットし、社内外でシェアすることでアウトプットしていく流れを作ろうとしました。

その結果個人的には社内表彰をされたりもしました。

しかし、それだけではアウトプットの文化作りという面ではあまり上手く行きませんでした。(特に他の人がアウトプットをし始めるとかはなかった)

そこで12月からはアドベントカレンダーのチャンスを生かし、普段アウトプットしていないが書いた記事を読んでみたい人に声をかけまくって、記事を書いてもらいました。その際、アイデアが出てこないという人とは壁打ちしたり、構成に自信がないという人はreviewをしたりしながら、アウトプット/知の共有の楽しさを伝えていきました。

結果Qiita Organizationのメンバーは当初の２倍以上になり、「書いてよかったし、これからも継続して書いていきたい」という声を聞くことができました。継続的に支援し、これからも多くの人が知の共有の大切さに気がつくきっかけを作れればと思っています。

qiita.com

プライベート

1月にギークハウスに引っ越した(2020/01/02 追記)

２５年間ずっと実家暮らしだったんですが、もうそろそろ外に出ないとなと思ったのもあって思い切って引っ越しました。 ギークハウスを選んだ理由は、ちょうど技術者として生きていく決意(転職)とともに住む環境もガラッと変えてしまった方がいいと思ったからです。 最初は西新宿の方に2ヶ月くらい住んで、その後代々木の方でずっとお世話になっています。

みんなで開発合宿したり、突然のLT大会で情報共有したり、おうちハックしたりエンジニアにとって最高の環境です。自分にないものを持っている人がたくさんいて、その人々と知のシェアリングができている感じが現代っぽくてとても好きです。 結婚したり同棲する人ができたりするまでは、シェアハウスでフラフラしたいと思ってます。

以下はみんなで作ったシェアハウスの鍵を開けるシステム

鍵システムの紹介と、Go/ラズパイ/Mackerelを使ったおうちハックの勧め記事 qiita.com

AWS SAA(認定ソリューションアーキテクト アソシエート)取得

入社当初クラウドなんもわからん、、チームメンバーの言ってることが全然わからん。。だったので、とりあえず冒険の地図を得る感覚でAWS SAAを取得しました。今振り返ると、入社直後にとったのは英断だったと思います。みなさん是非とってみてください。

qiita.com

モデリング会立ち上げ

ちょうどチームとしてもClean Architectureでリファクタしていくという流れだったのもあり、そもそもの根本のモデリングを学びたくモデリング会を立ち上げました。

geekhouse-shinjuku.connpass.com

fukubaka0825.hatenablog.com

非常に得るものも多く常に定員の２倍くらい応募のくるイベントでしたが、３回ほど行った後Developer Productivity/IaC/SREという領域に興味がかなり移行してしまい、しばらく行えていません。 どこかで再開したいと思っています。。

Gopher道場卒業

Gopher道場とは、Go Conの主催者でもあるtenntenn氏が定期的に開催している体系的にGoをみっちり学べる勉強会です。 課題を提出し無事選考を通り１ヶ月講義と課題をこなし、最後にLTをしてGopher君Tシャツをもらい卒業しました。

gopherdojo.connpass.com

qiita.com

結果、Table Drivenテストやエラーハンドリングについて特に理解を深め、現場にも持ち帰り導入できたし、何よりGoを学ぶ熱量が高い仲間ができたので非常に有益でした。

技術書典7で技術同人誌初執筆

私はギークハウス新宿というシェアハウスに住んでいるのですが、仲良くさせてもらっている住人(@wamisnetや@samuraikun(元住居人))など技術書執筆経験者が非常に多く、技術書典6に参加し感化されたのもあって技術書典7に参加し技術書を頒布することとしました。

非常に多くのトピックを扱いすぎたり、なかなか執筆のエンジンがかからなかったりで非常に苦労しましたが、住人のサポートのおかげで記事のアウトプットでは得られない経験がたくさんできたので非常によかったです。

fukubaka.booth.pm

note.com

技術書典8は出られないですが、技術書典9では何かしら書くつもりでいます。

SRE NEXTの運営メンバーに加わった

9月に参加したSRE Lounge #10でSRE NEXTなる日本初のSRE Conferenceが開催されるということ知り、昔からdevops/基盤に関する関心が強かったこともあって居てもたっても居られず、気がついたら主催者のkatsuhisaさんTwitterのリプで「是非お手伝いさせてください！」と送っていました。 そうして、運営メンバーとして参加させていただくこととなりました(何処の馬の骨かわらない僕を入れてくれたことに感謝！)

sre-next.dev

私が具体的に何をやっているかというと、Twitter運用/ブログ記事作成/イベントチケット管理/動画制作の取りまとめ などなどをやっていっています。

ちなみにSRE NEXT 2020は2020/01/25開催ですが、もう一般チケットは全てSOLD OUTしてしまっています。

しかし非常にハイレベルはセッションばかりなので、参加できない方も後からスライドをチェックしたりしながら活用していただければと思います。 参加者の方はスタッフ一同、急ピッチで準備進めており、素晴らしいイベントにしますので当日はよろしくお願いいたします。

記事をたくさん書いた

数えたら、はてなブログ、Qiita、note、medium合わせて今年で54記事書いていました。Qiitaで何個かバズったりして、合計2000いいねを超えたりしました。

f:id:st5818129:20191231184833p:plain

一方、アウトプットが散らばってしまいとても見辛い状況になってしまったので、年末に自身のキャリアとアウトプットを集約したポートフォリオサイトを整備しました。

www.fukubaka0825.dev

来年も質を向上させながら継続していきます。

来年一年何をしていきたいか

業務

SRE/Platformerとしての経験を積みたい

現在はいちWeb Developerとしてアーリーな時期のプロダクトにSREの種を植えていっている(IaC,CDなど)状態ですが、片手間ではなく体系的にSREを学び実践していきたいと考えています。(弊社だとこれからUS展開などで開発の方により一層リソースを割かざるおえない)

というのも、もともとドラマーであることも起因しているのか、ビジネス成功可能性を最大化する基盤/開発者の生産性向上への興味関心が何よりも強く、DeveloperとしてというよりSREのスペシャリストとして勝負していきたい思いが強くなったからです。

ですので、グローバルサービスのSREを募集している企業様がありましたらぜひお声がけください。必死でキャッチアップし食らい付き、お役に立つ自信はあります。

プライベート

OSS活動を活発に

最近Goで一つツールを作ったり、terraform-aws-providerやtfnotifyなどへコントリビュートしたりしていますが、この流れをより加速させていきたいです。

qiita.com

qiita.com

具体的には、OSSへのコントリビュートは最低月1で、OSSツールは2ヶ月に一回作成し、50スター以上の皆に愛されるツールを最低1つ作ることを目標とします。

アウトプット改善

質を高める

社内ではreviewしたり壁打ちしたりしている立場ですが、正直自分のアウトプットに関して少し限界が見えているなと思っています。 ですので、この機会にカックさん(有名なブログメンター)のメンタリングを受けたりしながら一旦自分のスタイルを再構築したいと思っています。

英語のアウトプットを増やす

現状、英語用のtwitterアカウントも英語記事用のmediumもうまく活用できてるとは言えないので、これからmediumには最低月2回記事を載せ、twitterも日常の勉強内容をつぶやいていこうと思っています。

登壇を増やす

今年の登壇回数は二回と、お世辞にも多いとは言えませんでした。 記事を量産できたのはいい点ですが、アウトプットの場としてこちらの割合も上げていきたいです。(最低でも月一回LTする)

また、大型カンファレンス(Go Con,SRE Con,SRE NEXT)などのCFPにもプロポーザルをどんどん出していきたいです。国際的なカンファレンスでの登壇を目標に頑張ります。

CS (Computer Science)力の強化

文系卒developerあるあるですが、CSの素養がきちんとあるとは言えない状況です。 将来的にはCSの学位か博士を取っていきたいですが、当面はまずアルゴリズムとデータ構造は螺旋本、ネットワークに関してはネスぺを取得するなどなど書籍や資格勉強で補填していきながら、業務の中でブラッシュアップさせていきたいと思います。

最後に

Global ServiceのSREを募集している企業様、是非お話を聞かせていただきたいです。TwitterのDMからご連絡お待ちしております。

読まれやすい文書を書く/継続して記事を書くコツ

技術発信のススメ

はじめに

どうもお久しぶりです。fukubakaことnariです。

7月に、技術発信を評価され、社内表彰していただきました！(そこからも必ず週１のQiita投稿はキープできている)

その際のfeedbackのなかで、 「どのようなことを意識して記事を書いているのか」 という質問がありまして、Qiitaの限定公開の社内のみで共有していたものをはてブで社外にも共有しようと思い、こちらにも転載しております。

非常に簡易なものですが、どなたかのお役に立てれば幸いです。

読まれやすい文書を書く３つの方法

1.まず大枠のプロット(目次)を打ってから書き始める

## TL;DR
## はじめに
## そもそもxxって？
## どんな人にxxはおすすめか(リコメンドじゃないなら想定読者とかでもok)
## なぜxxをしようと思ったか
## どうxxしたか
### 1.yyyy
### 2.xxxx
### 3.zzzzz
## 終わりに

2.結局5W1Hが重要なので意識して書く

WHOM

  • 誰に向けた記事なのか明記す

WHAT

  • 作った系ならまず何を作ったかを出す
  • 長くなりそうならTL;DR(Too long; didn't read.)を要旨として最初に書く
  • 取り扱うトピックについて、そもそもの説明は最初にサクッと入れる(間口を広げる)(ex:そもそもAWSアーキテクトって？ CIって？)

WHY

  • なぜ作ったか、そうしたか、記事を書いているかはなるべく書く

WHEN

  • いつ時点の情報なのかを意識してかいておく(後日訂正の時は特に)
  • 時間軸を意識する　過去の話、今の話、未来の話
  • 未来の話はできれば入れる 今後どう発展させていくか、fixするか

WHRER

  • どういうシーン、どこで起きたことなのかをできれば書く これはおまけ

HOW

  • HowはStepsに分けて書く(ex:1.手を洗う 2.材料をきる 3.鍋にぶち込む)

3.図を多用する

  • 必ず1枚でいいので入れると読者が読みやすくなる
  • draw.io なんかでシステム関係図を起こして載せる
  • マインドマップで事象の紐付きを整理して掲載

継続して記事を書くコツ

  • 完璧主義をやめる　不完全なものをまず出してから、ブラッシュアップしていくスタンスへシフト
  • 自分の思考を整理することになり、feedbackをもらうチャンスになるため、結局自分が得することを知る
  • 一回かいてみて、誰か一人の役に立つだけで嬉しいことを知る
  • とりあえずを増やす　ex:だるいけど、とりあえずプロットだけ打とう

モデリングがやりたすぎて、アーキテクチャ勉強会を立ち上げてみた話

アプリケーション設計

はじめに

ご無沙汰してます。 nariです

この度、アーキテクチャ勉強会を発足し、初回はモデリングハンズオンのイベントをconnpassにて立ててみました。

すると、、、、

geekhouse-shinjuku.connpass.com

結構な反響で、今回のイベントの会場であるギークハウス新宿というシェアハウスのキャパがゆうに超えてしまう応募がありました。

 

参加型の設計イベントを探している自分のような人間が他にも沢山いるのではないかという憶測はあながち間違ってなかったみたいです。

  当日のイベント資料はこちら↓

www.slideshare.net

アーキテクチャ勉強会発足のきっかけ

1.モデリングを定期的にやりたい欲が爆発した

上記のツイートのように、BIGLOBEさんの本を技術書店で買い、たまたまその後参加したモデリングハンズオン がBIGLOBEさん主催で、定期的にモデリング会やりたい欲が止まらなくなったためです笑

また、今後はDDDやマイクロサービアーキテクチャなど広範な設計の勉強をしていきたかったため、 このような名前で発足しました。

2.自分の住んでいるシェアハウスが活発にイベント開いていく流れを作りたかった（外向けにも)

私はギークハウス新宿というエンジニアが共同生活するシェアハウスに住みはじめたのですが、思った以上に 勉強会や知の共有がされていない、、

せっかくギークハウス住んでいるんだから、各々が刺激しあいアウトプットしていく集団にしていきたいなという 話を、同じく住人の wami さんと話していて、その契機になればいいなと思ったのも一因です。 (アウトプットするところに知識は集まっていくと思っています。)

当日のイベントの概要

  • テーマは「会議室予約」
  • 言語はGolang
  • 4(5)人一つのチームで別れる（A,B)

私が以下のようなUsecaseドキュメントの準備まで済ませ、そこから名詞や動詞を抜き出して、 ドメインモデルを作っていく流れにしてみました。

# 会議室予約api仕様
## 会議室(マスター)
スサノオ
アマテラス
ツクヨミ
## 予約単位
１h(ex. 1400~1600)
## 予約可能時間
900~1800
## UseCase
- 会議室と時間を指定して、会議室を予約できる。
- 予約に成功すると、予約の詳細が帰ってくる
- 時間可能範囲外の時間帯に予約がくると、エラーを返す
- すでにその時間帯に予約があって予約ができなかった場合、すでに入っていた予約のリストを返す
## test前提
- 5/27 スサノオ 1200-1300,5/27 アマテラス 1300-1500,ツクヨミ 1200-1300と1400-1600の予約が入っている
- 上記の4件だけ入ってる想定で
## testケース
- 5/27 スサノオ　1300-1400の予約は成功し、その予約の詳細を返す
- 5/27 アマテラス 700-800の予約は失敗し、エラーを返す
- 5/27 ツクヨミ 1200-1500の予約は失敗し、1200-1300と1400-1600の予約
## issue
- 予約者マスターができて、adminの人だけツクヨミを予約できるようにする

今回のUseCase外の仕様の話が出てきたら、各チーム別でissueとして管理することで、 議論の発散を防ぎました(issueは追加要件として後日採用)

当日のイベントの予定

  • 自己紹介(1810~1820)
  • ユースケースの確認(1820~1830)
  • モデリング開始　名詞と動詞を抜き出す 状態遷移図 クラス図(1830~1930)
  • 現状のモデルシェア、チームでfeedback(1930~40)
  • testcase通る想定まで実装とモデリング行き来(1940~2040)
  • KPT(2040~2050)
  • KPTとissueの共有(2050~2100)
  • 懇親会(2100~2200)

当日の様子と各チームモデルとKPT

Aチーム

f:id:st5818129:20190528015441j:plain f:id:st5818129:20190528015805j:plain

Bチーム

f:id:st5818129:20190528015754j:plain f:id:st5818129:20190528015836j:plain

それぞれのissue

f:id:st5818129:20190528015825j:plain

(他にも状態遷移図や業務フローなど色々図を作成したのですが、写真を撮り忘れました、、)

反省点

  • それぞれのDDDの理解段階が違うことを顧慮すべき。最初にそもそもDDDとは、モデリングってどの層の話か、頻出単語集くらいは共有すべき
  • testcaseやdomain層以外の実装を終わらせておいて、スムーズにdomainと実装を行き来できる状況が作れなかった
  • 少しスケジュールを詰めすぎた 休憩をもうけるべきだった
  • 図で表現する力の弱さを実感した 積極的にUMLや状態遷移図などで表現する癖をつけるべき

終わりに

初回は色々と反省点も多かったですが、こういった性質のイベントは長い目で見るべきなのかなとも思いました。

そして、やっぱりみんなでわいわい設計を実際しながら議論するのは楽しい！！！
(僕やその他酒好きは、懇親会に先立ち酒駆動設計してました笑) 　　

ここから実装や仕様追加しながら、みんなで仕様変更に強いdomainを育てる感覚を養っていきたいと思います。 (とりあえず、会議室予約システムというお題は継続する予定。簡単そうで意外と考慮すべき点が多く、かつ会議室と予約どっちをコアドメインにするかで違いが出る、良いお題でした。)

次回以降もレポ書いて、モデリング力を磨いていく仮定を記録していこうと思いますので、今後ともチェックしていってください。 　

2週間に一回やっていく予定なので、参加型の設計イベントに参加してみたい、あなたのご参加もお待ちしております !　　

現状少人数ですが、知見が高まれば将来的に大勢で会議室を貸し切って、モデリング布教活動もやっていきたいですね。 　  

1週間でLPICの基礎が学べる本 書評

書評

目次

はじめに

どうもご無沙汰してます。
服バカエンタメエンジニアのnariです。
最近は、GolangデビューしたりAWSアーキテクトのアソシエイトとったりしてました。

さてさて、今回はというと、

kuwana-kb.hatenablog.com

この書評が素敵だったので、私も真似して自分の学習の記録として始めることに
(kuwanaさんみたいに、概念の説明とかは多分書いていかないかな？)

www.amazon.co.jp

1行で言うと

１週間でlinuxOSの歴史と仕組み、linux環境作成、基本操作などについて一通り学ぶことができる本

経緯

アプリ開発などでざっくり一通りコマンドは抑えたが、漏れや理解が不十分なところがたくさんあったので 会社にあったこれをサクッと一周終わらせることに

内容紹介

良かった点

  • 全体的に１ページの情報量が多すぎず少なすぎないため、学習時の負担が少ない
  • 図もふんだんに入っているため理解が進みやすい
  • 注釈の説明がしっかりしているため、なぜが常に解消された状態で知識を落とし込める

改善点

  • コマンドライン引数、ストリーム、HTTPサーバなどのお話も少しあるとより良い
  • ShellScriptに関してもう少しだけ踏み込んでくれると嬉しかった

こんな人にオススメ

  • なんとなくでコマンドを叩いてしまっているサーバーサイドビギナーエンジニア
  • 他の学習との兼ね合いで、まずはlinuxに必要最低限の部分だけにリソースを割きたい人

逆にがっつり原理原則からLinux学びたいんじゃ！って人は以下の本がオススメらしいよ(先輩に聞いた)

標準テキスト CentOS 7 構築・運用・管理パーフェクトガイド

新しいLinuxの教科書

得られたもの

  • ディレクトリのtmpとかbinとかvarとか、ふわふわした認識でいたが、役割を整理(FHSの学習)
  • homeとルートディレクトリをフィーリングで区別して作業していたが、ここで確固たる理解
  • ハードリンクとシンボリックリンクを差別化できた　rmがiノード番号との関係性を断ち切っているだけだと理解
  • アクセス権とパーミッションについて整理
  • viコマンドの整理
  • リダイレクトとパイプを理解
  • 環境変数とシェル変数の違い、プロセスとジョブの理解
  • シェル、パッケージ、ファイルシステムの基礎

今後

コンパクトにサーバサイドの人間の必要最低限のlinuxに関する知識がつく一冊で、とてもオススメ。
学習していてもっと深くリナックスが学びたいなあと言う思いが募った。

得た知識をベースに、カーネルやOSの仕組みの理解を深めていくこともしたいが、
とりあえずはShellscriptの勉強を進めて実務中心に具体の部分に多く触れて精通していきたい。

時期が来たら、入門UNIXシェルプログラミング やって、 ふつうのLinuxプログラミング 第2版 Linuxの仕組みから学べるgccプログラミングの王道 もやっていってシェルやカーネルのもう少し深いところまで学んでいく
すぐに取り掛かるわけではないけど近々必ず !
（ギークハウスの住人がどっちも持ってたのでやってみるという感じ)

次の書評予定

みんなのGo言語【現場で使える実践テクニック】 を予定

今の所最高に面白く、かつためになります。

== 追記 2019/03/24 ==

私の大学の学部の先輩からのアドバイス！みなさま参考にしてください