progrhyme's tech blog

主にIT関連の技術メモ

サービスメッシュについて調べた

はじめに

最近、「サービスメッシュ」という語を見聞きする機会が増えた。
概念を正しく理解しておきたいと思って、このところ調べていたので、ここにまとめを記しておく。

サービスメッシュとは何か

TL;DR

Microservicesとして構成される分散システムにおいて、サービス間通信を担う専用のレイヤ。
サービスディスカバリ、負荷分散、トラフィック制御、通信のセキュア化などの機能を実現し、個々のサービスから利用可能にする。
代表的なプロダクトとして、 IstioLinkerdが挙げられる。

出典

上のようにまとめるにあたって参照した記事、文書、書籍を紹介する。
若干、相互に食い違う内容があったので、適当に自分が穏当と思うように取捨選択した。

私の解釈

もはや、当該レイヤで動作する(ソフトウェア)システムと定義してしまった方がしっくり来る。
なぜなら、上で述べたような機能を提供するもの(として認知されてきている)なので。

「service mesh」という語が登場するようになった当初は、単にMicroservices上のネットワークを指していたような表現が見られるが、いつの間にか「そのレイヤで動作するソフトウェア」という意味で述べられることが普通になってきたような気がする。

プロダクト

2018/8/11現在、自分が把握しているもの:

  • Istio
  • Envoy ... CNCF Incubation Project. Istio内ではプロキシ機能を担うコアコンポーネント
  • Buoyant社製品(※OSS)
  • Consul ... いつの間にか「distributed service mesh」となっている。また、Connectという新機能でsidecar proxyや通信の暗号化が実現される。

アーキテクチャ

サービスメッシュは上で述べたような概念のシステムなので、その実装は色々あり得るはずだが、IstioやLinkerdが事実上の標準実装となっているような向きがある。
正直、まだそんなに踏み込んで見てないのだけど、それらの構成要素は一致しており、よく似たアーキテクチャーとなっているようだ。

Istioのドキュメントから図を引用しておこう。

図: Istio Architecture

サービスメッシュ・システムの標準的な構成要素:

  • Data Plane ... サービス間の通信レイヤ
    • Sidecar Proxy ... 個々のサービス・プロセスとともに配置され、in/out双方向の通信を中継する。
  • Control Plane ... クラスタ内に配置される独立したサービスで、様々な中央集権的機能を担う。例えば、プロキシの管理を含むData Planeの制御や、設定変更のためのAPIが挙げられる。

その他参考:

サービスメッシュが必要とされた背景

既に上に挙げたWilliam Morganの記事から、内容をかいつまんで訳す。

大規模なMicroservicesシステムはGoogleNetflix, Twitterといった巨大企業で発展していった。
アプリケーションが多数のサービスに分割され、複雑化する内に、汎用的な通信レイヤが必要とされた。 しかし、それらは「重厚なクライアントライブラリ」の形を取った。
TwitterのFinagle, NetflixのHystrix, GoogleのStubbyが具体例だ。
それらこそが最初の「サービスメッシュ」だと言える。

この「重厚なクライアントライブラリ」の問題点は、以下だ。

  • ライブラリによって、アプリケーションの開発言語やフレームワークが強制されてしまう
  • 一方で、コンテナの普及により様々な言語で作られたサービスが動作することが普通になった

従って、「ライブラリ形のアプローチはもはや現実的ではない」と述べられている。

サービスメッシュが登場した歴史

LinkerdとEnvoyのどっちが先だったかわからないが、どっちかが最初だと思う。

2016年:

2017年:

他にもっとこんなのあったよ、という情報をお持ちの方がいたら、教えていただけたらここに追記するかもしれません。

終わりに

以下、雑感。

それなりの規模のMicroservicesを運用しているところだったら、なんらかの形でサービスメッシュ的なものを使っているのではないか。
一歩引いて、自分たちの環境におけるサービスメッシュに相当するものは何か、と考えると面白いかもしれない。

大規模で、コンテナを使ったサービスでMicroservices化された環境だったら、Istioなどの製品は相性が良さそう。

参考

*1:https://conduit.io/ Kubernetes向けの軽量Service Mesh

『インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門』を読んだ

ネットワーク系の知識を補強したくて、『インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門』という本のKindle版を買って読みました。

読了して、なかなか良い本だなと思ったので紹介しておきます。
特に、駆け出しのインフラエンジニアやネットワーク経験の浅いエンジニアにオススメです。

2013年の本ですが、ほとんどの内容は現在でも通用すると思います。

良かったところ

  • L1〜L7まで概観して基礎知識が押さえられる
  • 運用を踏まえており、実践的
  • 図表が多くてわかりやすい
  • 冗長化含む構成例があるのが良い
  • 各種プロトコルの復習になった

悪かった / イマイチかもしれないところ

  • Kindle版が固定レイアウトのため、不便
  • 1つひとつのトピックについてそんなに深くはない

過去に読んだネットワーク系の本について

今回以前にネットワーク系の本をちゃんと読んだのは、もう随分前だったように思います。
社会人になる前後ぐらいの時期に、『マスタリングTCP/IP』の入門編応用編と『図解・標準最新ルーティング&スイッチング』という本を読んだことを覚えています。

当時とは変わってしまった常識もちらほらあるように思います。

まとめ

『インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門』という本を紹介しました。

インフラやネットワークに携わるエンジニアの方々の参考になれば幸いです。
インフラ専業でないエンジニアが、予備知識のために読む本としても良いように思います。

よろしければ、どうぞ。

おまけ:疑問に思ったこと

ほとんど余談ですが、この本の中では「サーバサイト」という言葉が注釈なく出てきます。
文脈からすると、「サーバ機器が設置される場所」という意味っぽい。

Healthtech Meetup #1 でLTしてきた

昨夜、縁あってこちらのイベントでLTをさせて頂きました。

今回は記念すべき第1回のイベントだったわけですが、私の属する会社含め、都内でヘルスケア関連の事業を営む複数のテック企業による合同イベントという形で開催されました。

そんなわけで、各々事業内容やサービスの内容を紹介しつつ、その裏側の技術要素に触れ、掘り下げていくという形の発表が多かったように思います。

私のLTについて

発表資料は下になります。

他はストレートなタイトルの発表が多かった中で、少し異色な題名だったかもしれません。

m3.comは医療従事者向けのサービスであって、一般の人がそのアーキテクチャー等を意識することはほぼないでしょうが、見えないところでこういうものが動いているのだという話もそれはそれで面白いかな(?)、と思いました。

スライドをよく見ると、私がこの資料で示されている2015年のリニューアルに全く関わってないことがわかると思います^^;
…なので、識者に話を聞いたり、社内資料を漁りながら発表の準備をすることで、私自身がm3.comのシステムを学ぶ良い機会になりました。

他の方々の発表について

各社特色がありつつも、技術的な理想と現実の折り合いを上手くつけているな、と感じました。
どなたかの発表で「ロックインされたくないけど、なるべくマネージドサービスに寄せる」という話があって、頷けるものがありました。

発表ラインナップの中で唯一アカデミック色の強いものがあって、それはDeNA望月さんによる『AI x 創薬の最近の研究動向』という題のものでした。
AIとは、創薬とは何かに始まり、創薬における機械学習や深層学習の応用例などを紹介して頂きました。
ふだん参加するテックイベントでこういう話を聞くことは珍しく、とても興味深い内容でした。

これらの発表資料は、まだWebに上がっていないものもあるようです。
手元で雑なメモを取っていたものをGistに上げましたので、リンクを載せておきます。*1

もしご興味があれば、ご覧ください。

公開スライド

5/24 0:15時点で、Connpassにはまだ資料が上がっていないようです。
私が把握できているものを以下に載せておきます。

終わりに

今回は歓談の時間は少なめでしたが、近い業界の色々な話を聞けて良い刺激になりました!
第2回以降もぜひ参加したいと思いました。

ありがとうございました!

*1:自分の発表の前後の部分などはがっつり欠けていたりします。悪しからず。

Ruby Hack Challengeもくもく会 #5 に参加した

一昨日、Ruby Hack Challengeもくもく会に参加してきました。

初回のCookpad Ruby Hack Challengeは昨年の8月末でしたね。
当時から興味のあるイベントだったのですが、記憶によれば、予定が合わなかったり抽選で漏れたり諦めたりしたようです。

そんなわけで、初RHCでした。

事前準備

空手で行っても資料を元にもくもく作業はできそうでしたが、一応前日に少しだけ準備して臨みました。

GitHubに公開されているRHCの資料を読みながら、手順をなぞってRubyMac上でビルドしたり、C言語の開発環境を整えたり、といった作業をしました。

当日の流れ

会場はCookpadさんの12Fオフィスでした。
キッチンのある広いフリースペース的な場所で、少し大きめの勉強会などでも使われていると思いますが、今回は人数が少なめだったこともあって、1つのテーブルを囲んでみんなでもくもく作業しました。

自分は開始時刻の18:30ごろに到着したのですが、既に@ko1さん含む4名前後の方がいらっしゃってました。

PCを取り出すと、もくもくとRHC資料の続きを読みながら、途中の演習問題を解いていきました。
発展演習問題などは一旦すっ飛ばしつつも、一応最後の 5_performance.md まで読み切ったところで時間切れとなりました。

その間にばらばらと参加者が集まり、終了間際の21:00過ぎになってようやく全員で軽い自己紹介を行いました。

MacにおけるC言語の開発環境について

とても久しぶりにC言語のコードを書くことになったので、開発環境を整える必要がありました。

自分の短いRuby歴(2年弱)では、ずっとVimで開発していましたが、型のある言語だとIDEの支援を受けた方が効率が良いだろうと思っています。

そんなわけでIDEを検討したところ、まあMacだとXcodeがスタンダードなのかなと思いつつ、最近流行りのVS Codeを試したい気持ちになったので、今回はこちらを使ってみました。
私の観測範囲では、VS CodeはJavaScript界隈などで人気が高まっている気がしますが、Rubyもextensionがありますし、上手くすればなんでもVS Codeで書けるような気もします。

もくもく会までにバッチリ使い込むには至りませんですが、コードの読み書きでそれなりに支援を得られるぐらいにはなりました。

もう少しVS Codeを継続してみようかなと思っていますが、Mac上でのC言語開発について、良い情報をお持ちの方はお知らせ下さい。

gdbの代わりにlldbを使った

VS Code上でデバッグするまでは行かなかったのですが、rubyをビルドするためのmakeタスクで make gdbmake lldb が用意されています。 実行するとソースコードディレクトリに置いた test.rb を、その場でビルドしたruby(miniruby)を使ってgdb or lldbで実行してくれます。

初め、Macgdbを動かそうと少し試していたのですが、結局上手く行きませんでした。*1

lldbLLVMのライブラリを利用したより高機能なデバッガで、どうもMacではこちらを使った方が筋が良さそうです。

今後について

@ko1さんによれば、6月もRHCのイベント(おそらくまたもくもく会でしょうか)が開催されるそうです。

今回、私は下準備的なことしかできなかったので、できればまずは何か1つコントリビュートしてみたいなと思っています。
というわけで、来月以降も機会が合えば是非参加したいと思っています。

終わりに

イベントの開催、ありがとうございました!

GitLab Meetup Tokyo #7 に行ってきた

4/10にこちらのイベントに行ってきました。

気づいたときには一般参加枠が埋まっていたので、ブログ枠で参加しました。
…ということもあって、こうして記事を書いております。

最近GitLabを使うことが多いのですが、今回はコアな方々の話を聞けたり、今まで知らなかった機能やGitLabの思想にも触れることができて有意義でした。

はじめに

会場はサイボウズさんでした。

f:id:progrhyme:20180411000200j:plain

全体で90名ほどの参加予定でしたが、席はほぼ満席で、活気のある雰囲気でスタートしました。

始めに、GitLab Tokyo / GitLab JPの案内がありました。

Slackはどうやって入るのだろうと思ったのですが、HerokuでSlackinが動いているようですね。 検索すると見つかると思います。

発表スライド

Connpassに上がっているものもありますが、捕捉したものはここにも上げておきます。
(※随時更新します。)

Keynote「GitLabによるComplete DevOps」@shkitayama

LT①「How does GitLab manage git repositories?」@sotayamashita

LT②「GitLabのイシュートラッカー活用術」@jumpyoshi

LT③「GitLab CI & Docker in Docker」@toricls

LT④「カップラボ」@t_nakayama0714

LT⑤「State of Community Contributions to GitLab & GitLab 11.0」@tnir

感想

詳細な聴講メモは記事末尾に載せておきますが、ここでは印象深かった点を中心に簡単に感想を述べます。

@shkitayama さんの発表「GitLabによるComplete DevOps」では、GitLabが目指すビジョンについて知ることができました。
確かに、DevとOpsで別々のツールを使っていたり、様々なツールを使い分けることは弊害や不効率を生みかねない部分はあるでしょう。
全てがGitLabのような単一のツールで完結できたら理想的かもしれません。

また、GitLabに様々な機能が有ることは知っていたのですが、思った以上に更にパワフルになっていることにも気づきました。
CI/CDだけでなく、脆弱性分析やデプロイ後の構成管理、監視なども守備範囲に入っているようです。

@jumpyoshi さんのLT「GitLabのイシュートラッカー活用術」では、見やすいかんばんの画面も紹介されていました。

また、GitLabの内部構造についても知る機会がありました。
@sotayamashita さんのLT「How does GitLab manage git repositories?」は、GitalyというGitをRPCサーバ化したOSSが紹介されていました。
このGitalyがGitLab内でGit操作を行っており、フロントであるRailsとはgRPCで通信しています。

@toriclsさんのLT「GitLab CI & Docker in Docker」では、GitLab CIのExecutorの1つであるDocker-in-Dockerについて解説がありました。

終わりに

まだまだ使いこなせていない機能が色々とあることがわかったので、トライしていきたいと思いました。

懇親会では、スポンサーのクリエーションラインさんのご厚意により、美味しい寿司とビールを楽しむことができました。
ありがとうございました!!

聴講メモ

Keynote「GitLabによるComplete DevOps」

  • 自己紹介
  • アンケート
    • GitLab初めての人 ... 2〜3割
    • 使ってる, CI/CDしてる ... 5割ぐらい
  • 概要
    • GitLab進化してる
  • アジェンダ:
    • GitLab Complete DevOps
    • GitLab Development Lifecycle
    • ...
  • 本を書く上で気をつけていること
    • ツール ... 何かの課題を解決するもの
  • GitLabのビジョン
    • エンタープライズの開発チームがツールチェーンを維持する時間を短縮し、ソフトウェア開発に時間を費やす環境を提供すること
    • これ以外の使い方だと使いづらかったりtoo muchだったりすることもあるだろう
  • Traditional DevOps
    • Developers
    • Operators
    • それぞれツールを開発する
    • 交わるのはごく一部 ... デプロイとか
    • けっこう相容れないものがある
    • コンウェイの法則
      • 組織が分かれていると壁ができてしまう
    • どんなツールを使うか
      • Slack, GitHub, Jenkins, Artifactly, K8s, Ansible, Zabbix
    • 流れ
      • Idea => Plan => SCM => Build => Deploy => Production <= Monitor
  • 最近よくある質問
    • 「DevOpsいっぱいツールあるけどどれ使えばいいの?」
  • Complete DevOps
    • 変更を容易にするためのツールチェーンの管理をなくし、開発者と運用者のコラボレーションを促進するカルチャーシフト
    • それ全部GitLabでできるよ
  • どういう利点があるのか?
    • 可視化 ... real time view across the entire lifecycle
    • 効率化 ... collaborate without waiting
    • 統制化 ... develop and operate w/ confidence
  • Complete DevOps
    • Plan
      • chat ... mattermost(オンプレ版slack clone)
      • issue management
    • Create
      • Version Control
      • Code Review ... Merge Request
    • Verify
      • 静的解析
      • 回帰テスト
      • 脆弱性分析 ★ ... 注力している
        • Docker image ... Clair(OSS)を利用
        • DAST ... OWASP ZAProxy
          • GitLab CIで設定できる
      • パフォーマンス
    • Package
      • artifact ... ソースコードのセット
      • docker image ... こっちを管理しないといけなくなってきた
      • GitLabならdocker imageとソースコードを容易に1対1対応させられる
    • Release
      • K8s, Openstack, VMware連携
      • CD
      • Canary deploy ... Enterprise版
    • Configure
      • リリース後の環境に対して変更作業やデプロイ環境のプロビジョニングを行う活動
      • 単発の変更ではなく、継続的な構成管理の自動化を指す
      • GKEクラスタのconfigureもできる
    • Monitor
      • 性能監視 by Prometheus
        • K8sのメトリクス取れる
  • 今後も機能開発していく
    • Protfolio Mgmt
    • IDE
    • Security Products
    • Binary Repository
    • Logging, ...
  • Cloud Nativeとは
  • Cloud Nativeアプリケーションの利点
    • 開発者の時間を解放する
    • コンテナオーケストレーションを介して、アプリケーションリソースを監視し、スケールすることでコストを節約する
    • リリースサイクルを自動化して高速化できる
    • 顧客体験を向上する
  • GKE統合について
    • CI/CDタブにGoogleログインボタン => GCPにK8sを立てる
  • デモ
    • gitlab.comで
    • CI/CD > K8s
    • いくつかアプリケーションをK8sにインストール
      • Helm ... package manager
      • Prometheus ... 監視
      • GitLab Runner ... CI/CD
    • .gitlab-ci.ymlの build > tags でCIを実行するK8sクラスタを選べる
  • Summary
    • GitLab Vision
    • GitLab Components
    • GitLab's Cloud Native Apps
  • GitLabがGitHubをサポート
  • 宣伝

余談: 発表中、@shkitayama さんが「GitLab」を「ギットラブ」と発音していたところ、TLで少々物議を醸していました。

LT①「How does GitLab manage git repositories?」

  • 自己紹介
    • @sotayamashita
    • Locki 共同創業者
    • Node.js, Electron
  • 404ページ
    • たぬきに注意
  • agenda
    • Gitalyについて
    • Gitaly <> Rails サーバ w/ gRPC
    • ロードマップ
    • まとめ、今後
  • Gitalyについて
    • A Git RPC service for handling all the git calls made by GitLab
    • Railsサーバ
    • Gitalyサーバ ... gRPCサーバ
      • Goで書かれている
      • diskにアクセスする
        • NFSレイテンシを下げられる
  • なぜgRPC?
    • 最初はREST APIを考えていたが
    • Protocol Buffers ... 型がある。各種言語に対応
  • gem 'gitaly-proto'
  • Gitalyは愚直にgitコマンドを実行している
  • ロードマップ
    • Gitaly Version 1.0 (Q4 2017)
      • すべてのgit操作をGitalyで統一
    • Gitaly Version 1.1 (Q1 2018)
      • 過去のruggedのコードを削除
    • Gitaly Version 2 (Q2 2018)
      • キャッシュを利用してパフォーマンス向上
  • まとめと今後やりたいこと
    • GitalyをGitサーバとして使う

余談: GitLabのアイコンは狐じゃなくて狸。

LT②「GitLabのイシュートラッカー活用術」

  • 自己紹介
    • @jumpyoshim
    • 新卒2年目
    • スマホアプリのバックエンドをPythonで開発
    • iRidge
      • BackLogも使ってる ... 非エンジニア
  • タスク管理ツールを併用するのはなぜか?
    • 『GitLab実践ガイド』
      • 誰しもが全てのデジタルコンテンツを共有できるようにし、チームが刺激的に協力しあい、より良い成果をより早く達成できるようにすること
    • => GitLabをより使いやすくしよう!
  • Issue Board
    • かんばん
    • イシューの進捗度がわかりやすく
  • Issue Label
    • "suggestion" ラベルでアイディアを出しやすく
  • Slack Notification Service
  • External Issue Tracker
    • 外部のイシュー管理ツールと連携できる

LT③「GitLab CI & Docker in Docker」

  • @toricls
  • GitLab v4あたりから使っている
  • GitLabKit
  • Docker使える
    • shell executor
    • docker-in-docker ★
    • ...
  • runnerの中でdockerビルドする
    • ホストを汚さないで済む
  • .gitlab-ci.ymlの書き方
    • services:
      • docker:dind
    • :
  • デモ

余談: デモでスポットライト型のペンライトを使われていて、TL上で「あのデバイスはなんだ?」とデモ自体の内容よりも盛り上がってる雰囲気でした。

超かっこいいので、知らない人は製品紹介の動画とか見ると良いと思います。

LT④「カップラボ」

  • 無料のGitLab.com&その他で毎日オススメカブを見つけてる話
  • @t_nakayama0714
  • ここ数年思ってること
    • お金を増やしたい
  • マネーキングダム
    • GitLabのクローズドグループ
    • 良さげな株をピックアップしてリスト
  • 仕組み
    • Slack, AWS, GitLab
    • シーケンス:
      1. Hubotのcron
      2. AWSでジョブを実行
      3. 計算
      4. GitLab Pages更新
  • GitLab.comの良いところ
    • GitLab Pagesでページ公開できる
    • GitLab CIがついてる
    • ぐいぐいバージョンが上がって未来的
    • 無料

LT⑤「State of Community Contributions to GitLab & GitLab 11.0」

  • @tnir
    • GitLab Core team
    • Cloud Native Ambassador, CNCF
    • iRidge
    • https://github.com/gitlabhq/gitlabhq ... スターしてね
      • No.2 in Rails app
        • No.1 ... discourse/discourse
      • No.2 in Git SCM Web UI
        • No.1 ... gogits/gogs
    • contribution welcome!
  • GitLab 11.0
    • 6月リリース予定
  • Updates
    • GraphQL
      • Facebookが2015年9月発表
      • REST APIの後継となるか
      • PoCを経て2017年9月
      • Facebook GraphQLライセンス問題により見送り
    • K8s integration
      • まだまだ続く
      • RBAC認証
    • SAST(静的分析)
    • Cloud-native Helm chart
      • omnibus chartからCloud-native chartへ
    • API v3廃止
      • 4ヶ月遅れて廃止
    • その他の予定
      • 公式ページ見てね
  • Promo

スポンサーLT クリエーションラインさん

  • SPEED+ INNOVATION
    • 速く寿司をつくって提供する
  • DevOps
  • Chef, Docker, GitLab
  • GitLab
    • 国内唯一のリセールパートナー
  • MVPに3回選ばれた @hiroponz が4月からjoin
  • GitLab JPコミュニティの支援

Hugoのイケてるドキュメンテーション用Theme "Learn"と"DocDock"

はじめに

3年前(後述)に探したときは良いものが見つけられなかったのですが、時代は進んで便利なThemeが登場しているようです。
ドキュメントをHugoで作ると、Markdownでソースを管理できるのが良いですね。

この記事では主に"Learn"と"DocDock"という2つのThemeを紹介します。

Learn

Learn Theme for Hugo :: Documentation for Hugo Learn Theme

上がデモサイトにもなっています。

簡単に特長を紹介しておきます:

他にもいくつか機能がありますので、上のサイトを確認ください。

DocDock

DocDock Documentation

こちらは、Learnのフォークですが、作者はLearnにもコントリビュートしているようです。
LearnのREADMEにcreditが載せられています

Learnと違って多言語対応はしていませんが、独自機能としてreveal.jsによるスライド生成機能があるようです。

Bootie Docsとの比較

私自身も、3年前にbootie-docsというドキュメンテーション用のThemeを作って、ほそぼそとメンテを続けています。

正直に言って、bootie-docsよりもLearnやDocDockの方が機能が豊富で良さそうです^^;

特に、ドキュメントが増えてくると、メニューを一階層しか持てないBootie Docsでは苦しくなってくるかもしれません。

その他のTheme

ドキュメンテーション用のThemeは下のページを見ると他にもあります。

https://themes.gohugo.io/tags/documentation

ざっと見たところ、APIドキュメントを書くときはDocuAPIもよさそうだなと思いました。
先に挙げた2つのThemeは一般的な用途で使いやすそうです。

結びに

次にソフトウェアドキュメントを書くときには、LearnかDocDockのいずれかを試してみたいと思います。

3年前について

参考

Tour of Scalaを一巡りした

Tour of Scalaとは?

Tour of Scalaは、Scala公式サイトで提供されているScala初学者向けのチュートリアル的教材コンテンツです。
Golangの「A Tour of Go」のようなものですね。

Motivation

これに取り組んだ大きな理由としては2つあります。

  • Scalaが最近、身近でよく使われる言語になった。
  • 関数型言語をイチから学んでみたかった。

前者については、自分自身がScalaのコードを書く機会は今のところほぼないのですが、書けるようになれば話は変わってくるかもしれません。

後者については、意識して取り組んでいたのは、かつて大学の授業でSchemeを触っていた頃ぐらいでしょうか。
他にも、例えばRubyを書いていて知らず知らずの内に関数型プログラミング的なアプローチを取っていたことはあるかもしれませんが、どういうのがそれなのかと聞かれると明言しかねる状態です。

然るに、関数型プログラミングはやはり大きなパラダイムであるので、これを学んでおくことは今後も必ず役立つだろうと思いました。

どのように取り組んだか

Scala開発のための環境構築ログはこちら
IntelliJ IDEAでワークシートを作り、コードを貼って動作確認することが多かったです。

3/21〜24の4日間でTourを一巡し終えました。

以下は初学者向けのお役立ち情報です:

所感

Scalaについて、まだ機能の全貌は掴めていませんが、implicit機構など想像以上にパワフルな言語であることはわかりました。
一方で、LL並に簡潔に書けるような省略記法やシンタックス・シュガーがあることもわかりました。

関数型プログラミングについても、主要な登場人物らしき方々(第一級オブジェクトとしての関数、高階関数、カリー化、…)は現れたので、さわりぐらいは掴めたのかなと思います。

ただ、Tourを一巡しただけでは、特に関数型プログラミングについては学び足りないと感じました。

今後

そこで、上にも挙げたドワンゴのScala研修テキストの中で紹介されていた『Scala関数型デザイン&プログラミング』を購入することにしました。
こちらは、Kindle版だと50% OFFで購入することができました。

Scala スケーラブルプログラミング』(通称、「コップ本」)でないのはなぜかというと、どちらかといえば、Scalaよりも関数型プログラミングの方を学びたいからです。

関数型プログラミングを学ぶ上では他にも良書がありそうですが、ひとまずはScalaの学習も兼ねて、こちらの本で勉強を進めようと思います。